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 3 years ago.
Improve this question
My website application is using React for the frontend, and I'm deciding between ExpressJS or Flask.py for the backend. Either way, I know React has API fetching functions but also the other backend-dedicated frameworks. My question is, conventionally, would API fetching logic be part of the frontend or backend?
There are some conditions which require or prefer API fetching to be in the back-end:
When you need to use security credentials to access the API and you those credentials need to stay private.
When the API does not permit cross origin access so your front-end could not directly access it.
When you need to do some processing on the API results and you wish to keep the processing algorithms a trade secret (keep in mind that all processing done in the front-end is available for any coder to see). There are no secrets in the front-end code.
When the front-end device may not have appropriate resources (CPU, memory, etc..) to process the API results. This can particularly be the case with smaller dedicated devices.
When you don't want the front-end device to have to expend the battery energy to regularly access the API. This might particularly be the case if you're regularly polling some API looking for changes. In that case, you might want the back-end to do the polling and just let the front-end know when there is something to actually do.
When there are reasons to do some centralized performance management of your access to the API such as caching of results or request throttling.
When all front-end devices may not have proper network access to the API server.
If there are no compelling benefits to putting the API access in the back-end, then it may be more scalable (for your server) to let the front-end do as much work as it can.
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 2 years ago.
Improve this question
In order to deal with the website CORS problem,there are two options for me.
nginx reverse proxy
website fetch nodejs, nodesjs fetch the target, then send back only the part of data I need, which would be a 50% compression on size.
Considering the user experience
and the efficiency of server,
which approach is better ？
Thank you so much.
Reasons to use the generic reverse proxy:
You have a lot of different requests you need this for so it's simpler to have just one proxy that handles everything.
Using nginx removes all work in processing the proxied requests to a separate process so it doesn't cause any load on your nodejs server.
nginx "might" be more scalable than your own code in nodejs just because nginx is pretty highly optimized for these kinds of things. But, if this was a meaningful driver for your decision, you would have to measure to see if this was really the case or not (impossible to predict for sure without measuring).
Reasons to have your nodejs server do the work:
You can do application-specific authentication before allowing a proxy request to be used.
You can design application-specific requests that have your client specify only what you want to specify and your nodejs server can then translate that to the 3rd party website request, filling some parts with defaults, etc...
You can trim the proxy response to just the data your client needs, speeding up client responses and trimming server bandwidth costs.
You can combine multiple requests to the target into a single request/response between client and your nodejs server, allowing you to create more efficient requests, particularly on mobile or slow links.
Which is better depends entirely upon the specific requests and what exactly you're optimizing for. We can't name one as better than the other as they each have advantages and disadvantages so it ultimately comes down to which advantages and disadvantages matter more to you in your system.
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
I don't know if I see the benefit to an app service. It seems like with controllers and domain services you can get the same result. Can someone post a scenario when it would make sense to use an app service over controller/domain service?
Host independence - if your domain model is only exercised through HTTP calls, your controllers may be fine to keep complexity low but being able to call them from multiple hosts (think console application for an event queue, serverless, tests) can be beneficial. I am a fan of adding complexity as it is needed but unfortunately, a lot of developers will just copy the pattern that has come before. Especially if the initial plans have been lost to attrition.
Tests - mentioned above and pretty much just one side of the above cube but having the Application Service as a seam for writing tests against is often quite useful if you don't want to tie your tests to your host. Having said that, tools for testing ASPNET (an I am sure other technologies) in proc have come a long way over the years.
Reveal intent - Controllers, unfortunately, suffer from functionality gravitation. All functionality tends to be pulled into them. Are they accepting HTTP requests? Deserializing those requests? Converting to a command? To a model? Orchestrating the domain model calls for creating the model, domain services, repositories? What really is it's responsibility? The term service is soooo overloaded that teams I have worked with call Application Services Use-cases and name them for exactly what they are trying to exercise the domain to do.
Although you can of course use controllers as this entry point, you lose some flexibility but gain some initial simplicity. This is the exact balancing act you are playing when delaying the use of DDD adoption in the first place instead of standard MVC app with no strategy for managing complexity. Maybe if you are not seeing a benefit, the application has not reached the complexity needed to use DDD in the first place? It does come with a complexity cost.
With regard to domain service, they are really part of your domain and do the work whereas the application service is really the entry point that orchestrates the whole use case. Be careful of overusing domain services though, personally, I often view them as a failure on my part to find a decent model (but maybe that's just me).
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 1 year ago.
Improve this question
I know I am very bad at asking a question so please tell me rather than downvote me...thanx
Q1: How Is Progressive Web Application Useful?
Q2: What Type of Application Should be Built using PWA is there any Specific Application which contains a lot of CPU utilization or Simple Static Pages with just small interaction with Server?
Q3: What should be the Application Architecture? In General?
There are a lot of reason for using PWA rather than web-apps or native applications.
A1:To answer your first question there are some articles found on internet, here I recommend some of them to read:
Google Developers PWA documentation
What is PWA?
Important tips about PWA
A2: There are no limitation and restriction on app you wanna develop. (Also you should pay attention to the key things like caching, which are considerable and important in native/web apps, too.)
A3: The architecture is very similar to web-apps except it must have some additional files:
manifest.json (Which is used to declare something like application name, the icons and etc. and it must be placed in the root of the project)
serviceWorker.js (Which gives you additional features like push notification, background works and etc.)
NOTE: As it obvious your Progressive Web App should be responsive to support different resolution of mobile screens.
PWA is not a single technology or a framework , set of features in web which helps to improve your application progressively.
It means if you have a modern browser you will get an awesome user experience else those features just not support it , your application will have existing features remains as it is.
Let's talk about what all the features we can use to enhance our existing or new web application .
You can bring native look and feel of mobile device apps on your web
pages. It's not the responsiveness of web page but you can access the
native features such as camera , accessing geo location, push
notifications.
Offline Capability when your internet connection get lost through caching.
Background Synchronization of data
Icon on the home screen , you don't need to install the application
from the app store to place it on your home screen.
There are three import things I want to summarize about the progressive web application.
Reliable : Application will load instantly even in a uncertain condition and provide offline functionality through caching.
https://developers.google.com/web/progressive-web-apps/#reliable
Fast : Respond quickly as possible based on the user interactions.
https://developers.google.com/web/progressive-web-apps/#fast
Engaging : Feels like a native app on mobile devices.
https://developers.google.com/web/progressive-web-apps/#engaging
Q1: Progressive web applications (particularly the service worker part of them) are useful because they can (a) be very fast and (b) work offline. Using a service worker to cache resources (HTML, JS, CSS) on the user's device can create almost instant page-load times on subsequent visits to your site. In addition, this can make your site available even without a network connection. Progressive web apps (with a manifest file) can also be installed on the device home screen, making them easily accessible, like native apps.
I'm not sure I understand Q2 and Q3, so I'll leave those for someone else to answer.
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 4 years ago.
Improve this question
I have been learning full stack web development for a while now. But I am having trouble to understand where would the job of back-end developer stops, and front end begins when the work is separated.
I understand the back-end developer builds API that the front end developer will interact with, but I am confused regarding routing and (using nodeJS) who would write the equivalent of what is in the app.js file.
Finally, If you do back-end only, then you would not write any 'views.ejs' files?
Frontend development deals solely with the parts of a web application that a user interacts with, and requires HTML, JavaScript and CSS. The backend deals with the server, the application logic, and database.
If a single frontend developer is building a simple web application, they will have to create both the front end and the backend of the application. This may just require creating routes to render pages. Most freelance web developers do this.
For much bigger applications (in bigger organisations), the duties of the frontend developer and the backend developer are much more distinct. A backend developer will be responsible for building the actual application logic, checking for authentication and authorization, managing the database etc. The frontend developer in this organisation will work solely to design the interface that the user interacts with. They will not be required to even render any page on the backend. This is the job of the backend developer.
In short, a front-end developer may have some basic knowledge about the backend, but a backend or full stack developer will be required to build all the features of the application that a user does not see.
You read more about the difference using the following link: http://blog.teamtreehouse.com/i-dont-speak-your-language-frontend-vs-backend
The difference between back-end and frond-end developers is the program they wrote. Front-end deal mostly with the physical apparance of the website. How it looks and what user can physically feel while using the website. Front end languages include HTML, CSS, and Javascript.
While back-end developers focus mainly on the integration of server, web applications, and logic of the stylish web design made by front-end developers. They are in charge of creating a communication link between the website, the browser and the database servers.
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 8 years ago.
Improve this question
I am trying to understand what is the right tools for creating an app with text, audio and video exchange. As server-side tool i want to use node.js.
There is a lots of examples which shows you client-side code, but what about server-side? I know, that for WebRTC server is needed only for signaling purposes, but i cant find a descriptive giude helping me to find out how to say:"Hey, here is this guy, he wants to talk to you, so here's his IP" or something simmilar.
How to make sure that i am establishing direct conection? How to establish the most performant kind of connection? I know that there is some NAT traversal protocols, but how i can explicitly use/enable them?
Can i create distributed Skype-like network by connecting many-to-many peers and having some signaling/auth servers? Or maybe use some peers as servers for signaling only?
All the above can be obtained with software such as Flash Media Server (or Red5 for open source). If you want to use Node.JS, you will need to either create your Node services (message queue, media server), or use some already available, and have Node.JS handle the interaction between them. So all of these will be needed:
Node web service(s) with web sockets
Node / other message broker (mq)
Node / other media server (FMS, Red5)
Optional, a caching service for multiple Node web services (Redis)
You can choose Flash, it has great support for RTMFP/RTMP. If you really want WebRTC, you will have to create a STUN node service for p2p discovery, which is connected to the caching service to handle authorizations.
RTMFP is an option, webrtc too. Most performant depends on how you define performance: quality? latency? how should it be biased? If you want low latency, go for p2p. If you want recording capabilities, either rtmp or a node webrtc relay.
Yes, but you will most likely need a team to do that :)
Found almost all of the answers :)
There are no any restrictions for server-side tools, so you can use whatever you want. Node.js fits great. For communication purposes WebSockets or XHR can be used, but there is no restrictions for any others.
In the process of creating connections browser will generate some events with all needed data. You just need to send it to both sides and process it there. There is also offer/answer system, so connection can be made only with agreement from both sides.
Browser will try to establish best connection possible by default. If it's can't be done it will fallback to TURN, which translates data through server.
It will be possibe when DataChannels will be implemented.