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/
Related
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 details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
Is Azure appropriate for building an entire database-backed website, with custom tables on the backend, and custom pages, forms, and CSS on the frontend?
Like any database-backed website, there should be facility for backend logic in response to client-browser GET & POST requests.
Which Azure resources are appropriate? Logic Apps?
Sharing an answer i received on MSDN. (not sure yet if i will mark this one as best answer):
While is it possible, you have better options to consider.
If you are building a JS-powered frontend (using Angular/React), you could host the static assets directly on blob storage and expose it as a static website. The doc also covers how you could add a CDN to it for faster delivery to your customers.
The backend could be built entirely using Azure Functions. If you are using Table Storage or CosmosDB, there are bindings available that you could use and simplify the code that you would have to manage.
If you have background workflows (like batch jobs) that you have to run, then Logic Apps are indeed a good option. For complex use cases, Durable Functions might be a better fit though.
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 3 years ago.
Improve this question
When creating a bot in Azure Bot Service you have two hosting options according to this article: https://learn.microsoft.com/en-us/bot-framework/bot-service-overview-introduction
App Service Plan (Standard Azure web app, Web App Bot)
Consumption Plan (Azure Functions, Functions Bot)
I'm trying to understand the strengths and weaknesses of each. The billing model of a Function Bot would work best for my use case, but I seem to be finding limitations. It also seems that Microsoft's documentation is biased towards Web App Bots being the standard.
Here is what I know so far:
The billing model is different. App Services plans are billed more like an always running VM vs. Functions are pay-per-run.
App Service uses the standard ASP.NET MVC model. Functions use C# scripts
Visual Studio seems to have better support for debugging and publishing App Service plan bots
One thing I think is related to #2 is Global Message handling. The examples Microsoft gives for implementing a global message handler seems to require the use of global.asax.cs to register the global handler, this file isn't present in a Function Bot.
Are Web App bots the preferred option from Microsoft?
Is .NET Core better supported in either option?
Is there a way to implement global handlers in Function Bots?
Are there other specific weaknesses of Function Bots?
Is one option more "modern" than the other?
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).