I have a class "Firebase" in which I write all the functions (that involve this service) used in my server side.
At first, the code was pretty clean and clear, as there were not a lot of functions in this class. Now, the class is super giant (more than 100 functions not very short). This is why I have decided to divide the class into modules (maybe not correct) to improve the clarity and organization of the project.
Something like this:
/* eslint-disable no-empty */
const functions = require("firebase-functions");
const admin = require("firebase-admin");
// Lazy initialization of the admin SDK
try {
const googleCloudServiceAccount = require("../../utils/json/googleCloudServiceAccount.json");
admin.initializeApp({
credential: admin.credential.cert(googleCloudServiceAccount),
databaseURL: URL,
storageBucket: BUCKET,
});
} catch (e) {}
class Firebase {
constructor() {
Object.assign(this, {
auth: admin.auth(),
firestore: admin.firestore(),
storage: admin.storage(),
});
}
}
Object.assign(Firebase.prototype, {
/* Methods */
});
module.exports = Firebase;
What I have in mind is to organize the code in modules like "firebase-auth.js", "firebase-storage.js", "firebase-firestore.js"... and finally, require all the modules methods (or something better, because it can be a really long list of imports) and assign them to my Firebase class prototype.
My question is: If in the methods of the modules I need to use Firebase.firestore, Firebase.auth... (which are members of the Firebase class), should I create an instance of the class in each module?
Any ideas?
Thank you.
try this, is not best but works as expectly
create a file with functions in export module like:
module.exports = function (app, dbConnection, firebase) {
exampleFirebaseFunction(){
}
}
and in your main file you call it as:
require('./routes/firebase-routes.js')(app, dbConnection, firebase);
Related
So I am using firebase-admin in Next Js. I used environment variables but can't hide the firebase service account keys because they are not defined in server-side on Next JS. So i had to use NEXT_PUBLIC environment variables. And NEXT_PUBLIC environment variables can be accessed and viewed in client side.
This is my firebase-admin file
const firebase = require("firebase-admin");
const { fireStore, getFirestore } = require("firebase-admin/firestore");
import { adminConfig } from "./serviceAccountKey";
if (!firebase.apps.length) {
firebase.initializeApp({
credential: firebase.credential.cert(adminConfig),
});
}
export const db = getFirestore();
export default firebase;
And this is how my config object looks like.
export const adminConfig = {
type: process.env.NEXT_PUBLIC_FIREBASE_TYPE,
project_id: process.env.NEXT_PUBLIC_FIREBASE_PROJECT_ID,
private_key_id: process.env.NEXT_PUBLIC_FIREBASE_PRIVATE_KEY_ID,
private_key: process.env.NEXT_PUBLIC_FIREBASE_PRIVATE_KEY,
client_email: process.env.NEXT_PUBLIC_FIREBASE_CLIENT_EMAIL,
client_id: process.env.NEXT_PUBLIC_FIREBASE_CLIENT_ID,
auth_uri: process.env.NEXT_PUBLIC_FIREBASE_AUTH_URI,
token_uri: process.env.NEXT_PUBLIC_FIREBASE_TOKEN_URI,
auth_provider_x509_cert_url:
process.env.NEXT_PUBLIC_FIREBASE_AUTH_PROVIDER_CERT_URL,
client_x509_cert_url: process.env.NEXT_PUBLIC_FIREBASE_CLIENT_CERT_URL,
};
So How do i hide the config data. Or is it alright even if it is public?
I managed to do this in NextJS some time back (hopefully it's still relevant) - try this:
Store your secrets as environment variables in a .env file.
In your next.config.js load the environment variables in publicRuntimeConfig
publicRuntimeConfig: {
PRIVATE_KEY: process.env.FIREBASE_PRIVATE_KEY_ID,
PRIVATE_KEY_ID: process.env.FIREBASE_PRIVATE_KEY
}
Then in your client side React:
import getConfig from 'next/config';
const {publicRuntimeConfig} = getConfig();
const private_key = publicRuntimeConfig.PRIVATE_KEY
const private_key_id = publicRuntimeConfig.PRIVATE_KEY_ID
EDIT: Actually, now that I think about it, I used this method for things that didnt require absolute security like API_URIs.
Secrets stored/accessed like this will still be exposed to inspection in the browser.
For anything that requires securely storing secrets, definitely perform them on server-side.
I want to create an object that would import functions from another folder and it would look something like this:
class = {
functions: {
//All functions here
}
}
The functions would be inside of a different folder, however, I want to make some sort of importer in which it would make new classes for each new function/file it finds inside of the folder.
someFunction.js Function File:
function someFunction() {
console.log("this is some function");
}
So I would like for something to look like this:
class.functions.someFunction()
No, I do not want to have it hard coded into the object, I want to import all functions from a folder and create functions like that.
Well, first I wan't to answer your question as I think you want, even if I also think it is not the correct way to proceed.
I'll also assume that with class you are not referring to an actual ES6 Class, but we are talking about a plain object.
So this is the code:
const fs = require('fs');
const path = require('path');
function importer(dirPath) {
const absoluteDirPath = path.normalize(
path.isAbsolute(dirPath)
? dirPath
: path.resolve(process.cwd(), dirPath)
);
const output = {
functions: {}
};
const content = fs.readdirSync(path.normalize(absoluteDirPath));
content.forEach((basename) => {
const absoluteItemPath = path.join(absoluteDirPath, basename);
if (fs.statSync(absoluteItemPath).isFile() && /\.js$/i.test(basename)) {
output.functions[basename.slice(-3)] = require(path.relative(
__dirname,
absoluteItemPath
));
}
});
return output;
}
module.exports = importer;
For this to work, all your functions in your files should be exported like:
module.exports = function myFunction() {};
To use the 'importer', you just do:
const artemis = importer('/path/to/directory'); // PATH MUST BE ABSOLUTE OR RELATIVE TO CWD.
/*
SUPPOSING THAT YOUR DIRECTORY CONTAINS THE FOLLOWING FILES:
function1.js
function2.js
Then you can do:
artemis.function1();
artemis.function2();
Please note that your files must be named in a JS friendly way (a valid string for an object key).
*/
A final important note about this odd method: This will only ever work in a NodeJS environment. Even if functions could have worked in other environments (like a browser). The next method, will work for any ECMAScript environment after proper building process: transpilation (EX: Babel) and bundling (EX: Webpack).
Suggested Solution
Use ES6 Static import / export like modern JS libraries do. This comes with huge benefits, from static code analysis to tree shaking and more.
Let's suppose the following hierarchy:
// - index.js
// - internals/
// - index.js
// - module-1.js
// - module-2.js
internals/module-1.js
function module1() {}
export {module1};
internals/module-2.js
import {module1} from 'module-1.js';
function module2() {
// YOU CAN USE module1 IF YOU NEED. (AVOID CIRCULAR REFERENCES)
module1();
}
export {module2};
internals/index.js
import {module1} from './module-1.js';
import {module2} from './module-2.js';
export {module1, module2};
index.js
import * as moduleGroup from './internals/index.js';
export {moduleGroup};
Finally, where you import your moduleGroup, you can do:
moduleGroup.module1();
moduleGroup.module2();
Obviously this is a basic scenario, but this is, IMHO, the correct way to deliver a group of functions and other stuff. Please let me know if you have any doubt.
I want to be able to access all exports of a module without having to say module. before the export.
Let's say that I have a module:
// mymod.js
module.exports.foo = function() {
console.log("foo!");
}
module.exports.bar = "bar!";
And a main file:
// main.js
var mymod = require("./mymod.js");
mymod.foo();
Is there a way to call foo() without needing to say mymod. before? This can be achieved in python by saying import module as *.
What is the NodeJS equivalent to this?
In ES6 you can import modules in the following ways
import moduleName from "path/to/module"; // import default export from the file as moduleName object, moduleName can be anything
import { exportMemberName1, exportMemberName2, ... } from "path/to/module"; // destructured import, it will destructure import and can access the export module without prefixing anything
import * as moduleName from "path/to/module"; // import everything exported from the file as moduleName object, you can access every export members from that object, moduleName can be anything
These are the only methods provided by ES6 to import module (you can also use require).
If you have to import 100s of modules best ways is first method, import everything as an object and destructure on the go, I meant if you have lots of functions or methods, destructure what you want in that function in side that function, eg.
import * as moduleName from "path/to/file";
function function1(){
const { exportMember1, exportMember2 } = module;
}
function function2(){
const { exportMember1, exportMember5, exportMember7 } = module;
}
I want to be able to access all exports of a module without having to
say module. before the export.
Use the shorthand:
exports.myVar = myVar
exports.foo = () => {}
Or use an Object:
module.exports = {
foo,
myVar
}
// main.js
var mymod = require("./mymod.js");
mymod.foo();
Is there a way to call foo() without needing to say mymod. before?
This can be achieved in python by saying import module as *. What is
the NodeJS equivalent to this?
Use destructuring:
const { foo } = require("./mymod.js")
lets say that I have 100 exports in a file. Do I need to put commas
after every import inside the { }? There must be a better way to do
this
If you have 100 exports why would you want to import them all globally as their own functions? myMod.func is better for clarity.
A hacky workaround might be to do const myMod = require('myMod') then map it putting the functions on the global object. Or put them on the global from the start instead of exporting it.
You can use ES6 destructuring:
var { foo } = require("./mymod.js");
foo();
I have a situation where a I have a tiny-but-not-that-tiny generic utilities that is used along a couple of modules (all it's functions are used), in which there is a decent amount of modules already loaded. This functions are obviously named in a way you know there are a part of a generic utilities modules, so the "module.function" it's redundant, does not improve the readeability of the code. So, I prefered to mimick the "import * from module" of Python. Note that this is the first time I come across this situation, therefore, IMO, this mechanism, in almost every case, is not a good practice at all. The only way to do that, is iterating over the exports of the module, and adding the functions to the global object. I made a function to make the intention clear.
const importAll = () => {
return {
mod: null,
from(modName) {
this.mod = require(modName);
Object.keys(this.mod)
.forEach(exportedElementId => global[exportedElementId] = this.mod[exportedElementId]);
}
}
}
And it is used like this:
importAll().from('module-name');
Note that this only works if the module exports an object. Wont work if the module exports, for example, an array.
Here is another way, which may be a bit cleaner and more convenient in some cases: method importAll() is implemented inside export-heavy module, so it might be called immediately after require(), making this call very brief.
This works really well for large modules stuffed with simple standard functions and constants that are used across multiple projects.
Example:
// module.js
'use strict';
function func1() { return '4'; };
function func2() { return 2; };
function importAll() { delete this.importAll; Object.assign(global, this); };
module.exports = { func1, func2, importAll };
Then, in the main app, module can be unwrapped as follows:
// app.js
'use strict';
require('./module').importAll();
console.log("result: '%d'", func1() + func2());
There are few caveats though:
since properties/methods are added to global object, those might override some existing properties/methods, so be careful with naming.
those properties/methods will become available EVERYWHERE: in all modules, sub-modules, etc, so no need to call require() more than once.
Good evening to everyone.
I'm not sure how can I explain my issue. I will show it to you by showing examples of the code and expected results. I could not use code from the real issue because the code is under license. I am very sorry for that and I will be glad of someone can help me solve my issue.
I'm using latest version of webpack, babel.
My application is spliced to three parts what are dynamically imported by each other. It is mean if I run split chunks plugin it will really create three clear files.
The parts are Core, Shared, Application. Where the Core only creating an instance of the application.
Result of the parts is bundled to single file. So it is linked by one html's script tag.
Project structure is:
src/app // For Application
src/core // For Core
src/shared // For Shared
In webpack configuration I am resolving alias for import ˙Editor$˙.
I renamed naming of variables because they are including project name.
resolve: {
alias: {
"Editor$": path.resolve('./src/app/statics/Editor.js'),
}
},
The content of Core file is
function createInstance(name, id) {
import("app").then(App => {
App(name, id)
});
}
The little bit of Application file is
imports...
import Framework from "./framework"
function createApp(name, id) {
new Framework({name, id}).$mount(...)
}
export default createApp
In the Application classes (what are instantiated inside Framework)
Is this import
import Editor from "Editor"
The Editor class is a singleton. But only for created instance.
class Editor {
static instance;
id = null;
constructor(){
if(this.constructor.instance){
return this.constructor.instance
}
this.constructor.instance = this
}
static get Instance() {
return this.instance || (this.instance = new this())
}
static get Id {
return this.Instance.id;
}
}
export default Editor
The issue is webpack dependency resolving. Because webpack puts and unify all imports to the top of the file.
So the imports are evaluated once through the life-cycle of the program.
But I need to tell webpack something like: There is an instance creation. Declare the new Editor singleton for this scope. Don not use the already cached one.
My another idea how to fix this is to set context for the instance. And in the Editor singleton create something like new Map<Context, Editor> if you get what I mean. But I did not find a way how to set a context for an instance or scope the import only for it.
I will appreciate any help. I am googling two days and still no have idea how to do it without rewriting all the imports.
Sorry for bugs in my English. I am not native speaker and my brain is not for languages.
Thanks everyone who take look into my issue.
How about recreating the Editor:
// Editor.js
class Editor {
// ...
}
let instance;
export function scope(cb) {
instance = new Editor();
cb();
instance = null;
}
export default function createEditor() {
if(!instance) throw Error("Editor created out of scope!");
return instance;
}
That way you can easily set up different scopes:
// index.js
import {scope} from "./editor";
scope(() => {
require("A");
require("B");
});
scope(() => {
require("C");
});
// A
import Editor from "./editor";
(new Editor()).sth = 1;
// B
import Editor from "./editor";
console.log((new Editor()).sth); // 1
// C
import Editor from "./editor";
console.log((new Editor()).sth); // undefined
// note that this will fail:
setTimeout(() => {
new Editor(); // error: Editor created out of scope
}, 0);
That also works for nested requires and imports as long as they are not dynamic.
I am currently writing a lot of Firebase Functions and some of them share the same variables and functions.
At the moment I copy paste them in each Firebase Functions file, as they are siloed, but I don't know what would be the best practice to share the code between them? For the variables a config file would be cool, for the code, a class all Functions could inherit too, but I'm not sure how to do it clean?
Organization: at the moment I have an index.js file that is referencing all Firebase Functions that I have. Each Firebase Functions is a JS file. That's the hierarchy I have, not optimal nor maintainable...
Examples
Variables:
I currently have to write the API key of Mailgun in all my Firebase
Function:
getThisProcessDone() that I currently copy in all my Firebase Functions
Anyone already had the thought? Thanks for your help!
For my Functions projects, I've been putting my reusable resources into functions/lib and requiring them normally as npm modules. I've also been separating out the code used in Functions from the definitions, which helps with testing.
For example, consider this structure:
functions/
|-index.js
|-newWidget.function.js
|-lib/
| |-Widget.js
test/
|-newWidget.functions.spec.js
Now if I want to declare a trigger to handle new widgets, I do something like the following:
// functions/index.js:
const functions = require('firebase-functions');
exports.processNewWidget = functions.https.onRequest(require('./newWidget.function.js').process);
// functions/newWidget.function.js
exports.process = function(req, res) {
res.send('Hello world!');
};
// test/newWidget.function.spec.js
// Note how we can easily test our widget processor separate from
// the third-party dependencies!
const newWidget = require('../functions/newWidget.function.js');
describe('newWidget', () => {
describe('process', () => {
it('should send hello world', function() {
const req = {};
cost res = { send: () => {} };
spyOn(res.send);
newWidget.process(req, res);
expect(res.send).toHaveBeenCalledWith('Hello world!');
});
});
});
And to include a class called Widget from inside newWidget.functions.js, I do something like this:
// functions/lib/Widget.js
class Widget {
constructor(name) { this.name = name; }
}
exports.Widget = Widget;
// functions/newWidget.function.js
class Widget = require('./lib/Widget').Widget;
exports.process = function(req, res) => {
const widget = new Widget(req.param.name);
res.send(widget.name);
};
Having your functions under a GitHub repo and calling them from master branch isn't an option? I am currently importing like this in package.json:
{
"name": "functions",
"description": "Cloud Functions for Firebase",
"dependencies": {
"cex-converter": "https://github.com/joaquinperaza/cex-converter/tarball/master"
},
"private": true
}
then you just require your conde dependency like require('cex-converter') and you get the last release of your dependency and doesn't need to modify anything to deploy your last release.