Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
my situation is the following:
I have a REST API Node.js server using MongoDB, which will serve data to the clients.
I have one web client which will fetch data from the API service and provide social authentication.
For the purposes of my question, let's assume that I have two different clients - both web apps. In this situation, who should be responsible for social authentication, sessions, cookies, etc? The user database should be shared between all clients, but I feel like authentication and API should be two separate services.
What is the most common approach in this situation?
Client will be built with AngularJS, REST API service is built with Node.js, Express, MongoDB, Mongoose and eventually Passport.js when I figure it out.
Thanks
but I feel like authentication and API should be two separate services.
If you have to ask, you don't want 2 separate services. (services meaning independent network daemons/express apps)
Start with just 2 separate modules within your single express app. You can have an auth.js module that uses passport to handle authentication and session issues and then one module file for each entity in your API. If you need more than 1000 lines of code in your auth.js file considering passport is doing most of the hard work for you, something is going wrong. Take a step back and ask for a code review.
If you want each of your 2 web apps to have it's own Express server, just factor the auth.js module out into its own shareable npm module and require it from each web app.
Splitting things out into microservices is for large team projects at scale. Stick with a single simple express server for the first several years (or forever for projects that don't support a rapid-growth startup).
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 13 hours ago.
Improve this question
I have a react app and I am trying to figure out the best method to deploy it on azure. From what I see there are 2 methods but please let me know if there are others worth considering:
Azure App Service
Azure Static Web App
I can't work out what would be best for my scenario. I have authentication set up with MSAL library so I don't need to make use of static web apps built in Auth. I also do not forsee myself using the built in functions that come with static web apps. As such will they both be equally as good? Trying to figure out if there are any other differences I need to consider before depoloying.
React Single-Page Application is simply a bunch of files. You don't need a full App Service for this. Just serving static files is enough.
I can just quote an official doc:
Static web apps are commonly built using libraries and web frameworks like Angular, React, Svelte, Vue, or Blazor where server-side rendering isn't required. These apps include HTML, CSS, JavaScript, and image assets that make up the application. With a traditional web server, these assets are served from a single server alongside any required API endpoints.
https://learn.microsoft.com/en-us/azure/static-web-apps/overview
Here is the full set of documentation on Azure Static Web Apps:
https://learn.microsoft.com/en-us/azure/static-web-apps/
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
My friend and I are working on creating a product from scratch. We aim to build a cross platform application using react-native. We've planned to use firebase as our server hosting application.
Although, we both have fair amount of knowledge in react and have gone through some videos on react-native and firebase, mobile app development from scratch is still pretty new to us. We're having trouble to answer the following questions:
Where to start developement ?
Should we write our server in nodeJS and deploy it on firebase and my app can call the endpoints or should we connect to firebase directly from client side ?
How to setup configuration files and different environments for developement ?
These are among the many questions we have and we feel lost in this sea of infinite information.
Could anyone guide us here ? Please help me if I can frame my question in a better way.
React Native is a great place to start. With today's ecosystem lead by flutter and react, Angular has unfortunately fallen behind.
Both, Cloud functions are Firebase's solution to server instances, these create short-lived functions that do complex or secure tasks such as handle payments, delete/manage users, etc. While the bulk of your app and its logic with firebase should be handled on the client, including accessing the data so long as you have secure rules.
this depends entirely on your framework of choice but in general, there should be a build option that enables you to configure which settings to compile with.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I am curious with all the features of firebase, cloud functions, and client-side authentication, Firestore, etc. options, does it make sense to even use a 'backend' with a firebase web app? The reason I am asking is that I started a project with a react app and a node.js backend rest API service. I started to realize that with all of firebases features, it might make sense to scratch my backend entirely. What are everyone's thoughts? Thanks
You can use firebase directly without a backend (if it is just a simple project) but i'd recommend you to use it with a backend to be more secure, since the backend lets you check the recieved data if it is fake or not correct, also in order to hide your firebase's api key and other stuff like that, i have a firebase app on github (with front-end of react and backend of nodejs+firebase) i can leave the link of the repo if you are interested to check it out, thanks
Firebase is definitely a very good option for you. Since you are adept at using Javascript, you can use the Firebase JavaScript SDK and your backend is up and running
Google’s Firebase offers the following:
A very robust authentication service(Currently supports Google, Facebook, Twitter, Github, Email/Password and Anonymous authentication).
Realtime Database
Storage
Hosting
Cloud Messaging
Notifications
Analytics
Hope this help...
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Understood the concepts of Redux and Node theoretically - planning to use one of them? both? not sure - How do they compare to each other ? When creating a new app (using React for Example) - can we use both of them? or one of them should be enough? I am stuck with this question. What should be the criteria here? People with expertise with these technologies, please help.
nodejs is a library for writing server-side logic in javascript.
redux is a library for managing application state, either client-side or server-side.
For example, it is possible to build an application that uses redux to manage its state on the client. This application could then communicate to a server-side api that is built using nodejs. The server-side api could also be managing its local state using redux.
So you can see that the two technologies are not mutually exclusive, it is not nodejs or redux. Instead you can choose to use them for their respective purposes separately or in conjunction.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have an Express app serving a front-end web app.
How do I create an API server with /api as its root? I would like to separate the API concerns from the main app.
There are likely to be considerations over the intensity of connections to your API. That will be one of the leading factors in determining whether you really need a separate server.
In answer to your domain query, there are npm packages available to assist in creating an api subdomain if thats suitable https://api.example.com, but assuming it's a small to medium sized application, you'll be fine to use Express Router to achieve what you want. Details are here in the docs.
app.use('/api', router);
This will apply a filter to all requests so that only those with /api will reach this router like:
https://www.example.com/api/users/1
In fact, there could be an argument against prematurely optimising your app and building a second server. That said, if you modularise your code base suitably, then it should be a breeze to transfer the api routes over to a new server later down the line.
There is no best way. It all depends on how you want to do it. You can create an express router and mount it or create an express server instance and mount. See details here