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 2 years ago.
Improve this question
I am quite new to javascript and web application environment. I have seen an express web application project which had a public directory, a client directory, and a server directory. I have a questions
Why do we need an express server file setup in the frontend project
if we already have backend APIs ready and backend server ready
Any suggestion, please
(I have read some article from google, but I need your opinion)
Thanks.
This is a matter of choice.
Backend + frontend
You can use express as your backend server that exposes Rest API's to be consumed by the frontend.
You are then free to choose whatever frontend framework you like. The usual ones are vue, react or angular.
Server side rendering
You can use still use express as the backend and use it to render pages for the frontend (pages defined in the public directory)
Here's my two cents:
If I have the time on a project or if I work with different developers, I would go with separated Backend + Frontend. It is easier to maintain. You don't want frontend guys touching backend code and vice-versa. The separation is clear, we can also freely change the framework we use on the frontend/backend since we have a contract that we follow aka API's.
If the project needs to be done quickly and most of the pages are simple (don't need to maintain too much state, etc.), I would go with option 2.
It's really up to you and your team to decide.
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 6 months ago.
Improve this question
I basically have written a webapp from scratch. So I just used a index.html file and a bunch of js and css. Now I want to turn this into a Node.js webapp. How do I get this done in a way that doesn't require much changing of my existing code.
Node.js is designed to allow the server-side execution of JavaScript code. As, if I understand it right, this is a thing that you don't need I am curious why you want to use Node.js. The only thing you want to do is deliver your project files to a client (browser).
Although you could start a HTTP server which delivers the file of your project using JavaScript, this requires much of unnecessary boilerplate code that you don't need to write to get your project live. I would recommend using a regular HTTP server, which is designed to do exactly what you need: deliver files to the client.
Nginx is a lightweight HTTP server, which is easy to configure. Just set the root folder of your project as the HTTP root and nginx will deliver the requested file by itself.
To get started, head over to the Beginners Guide of nginx.
An alternative to nginx would be the Apache HTTP server.
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 understand I can design the UI with HTML CSS JavaScript or any other frontend framework.
I even understand that I can connect to any remote API.
what if I want a standalone application with database. How should I connect to the database ? where should I write my application logic?
I feel like there is a missing part in electron do I supposed to use a node JS web Framework like Express?
or I should write all the program logics in pure node JS without using any framework?
What is the best approach to write electron applications if possible please point me any working example.
It is entirely up to you.
While the client/server (frontend/backend) model we've got used to in web applications is a good idea (separation of concerns), it's not the only way to do things when the client and the server are on the same machine.
Electron is built on top of Node.js. So you can use the usual npm modules in order to connect to whatever database system you want to use and do away with frameworks. For example you can write code to fetch data from the database right into your onclick event handler if you desire so.
Having said that, odds are you will find yourself dealing with an unmanageable bunch of spaghetti code if you're not careful. So, some kind of structure is recommended even if you don't want an entire client/server system.
Also, your "client" and your "server" don't have to communicate through HTTP. The interface can be just plain function (and/or method) calls. Electron also has a message passing system (for example: https://electronjs.org/docs/api/ipc-main that you may use.
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 6 years ago.
Improve this question
We use repository pattern in Laravel 5.1 and kept our logic in repository and we return the data from repo to controller, how can we use same data for Native app and web browser (i.e. web application).....off course data is in json so how can we show same data in blade template...do we need to use another framework for front end (Angular or any other)?
I personally don't think you would need a package or framework to achieve this. Since you are following the repository pattern, your controllers are only in charge of returning results (optionally transforming them for output too).
To achieve your goal;
1- Group your API routes (etc. Route::group('api/v1', ...)
2- Create a class or even better a Trait to detect incoming routes
3- Either within your controller or on the class that handles JSON conversion, detect the route of the request.
4- If the request is being made from the api route, return JSON. Blade template otherwise.
You can also check out this link, which will help you building up your route detection. Also remember that you would need this exact implementation wihin your ExceptionHandler as well. You wouldn't want someone to see a json error message on your web front end, or a 404 blade template being returned from your API.
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
We are working on a large scaled web app that built on top of javascript frameworks and libraries (node, express/sails, angular, mongo etc).
We need to have a backend that from one hand serve the web application but on the other accept API calls for data (from the same app but from other origins as well) - very common these days.
One of the decision we want to take is should we separate the backend for Web Application server and API server or put them together.
For example should we have an express running serving both or should express serve the web app, static content, auth etc and have a separate Restify server serving the data.
What are the pros and cons for each agenda?
A clean separation of concerns is always the way to go. If, as you said, your API-Server takes calls also from other Apps, I would suggest you separate the delivery of static files and your API. It leaves your more flexible in changing the way one or the other works. Another benefit is that your API only needs to worry about API Calls and not the delivery, which should make it answer even faster.
I'm gonna take this one even further and say: Use nginx to deliver your static Web-App files (if you are not working with server side templating). See also this Thread - nginx is faster with delivering static sources.
In my company, this is how we do it for every App and it turned out to work just great.
So the Pros:
Better performance for both - static delivery and API
Clean separation of concerns
More flexibility in changing one or the other
The only con is that you need to install and maintain two programs. But given that NodeJS is super easy to set up, that shouldn't be a showstopper.
EDIT
As state by mnemosyn in the comments, if you separate your apps, you should still pull every request through the nginx Server to avoid some same-origin-policie issues. Within your nginx, you just have to configure a virtual-host pointing to your NodeJS-App and then proxying all request to a specified path (for example /api/) to that VHost. You can read about it here.
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 9 years ago.
Improve this question
We are building webapp and I have troubles deciding how to get data from the server.
On frontend we have angularJS and HTML. On the backend we have NodeJS, MongoDB, Mongoose and Express. As a templating engine we user JADE.
Now, what is the best way to fill the templates? Getting the data on the server while loading the partial or load the data through AngularJS using $http?
I am looking for the most effective and fastest way. Any thoughts?
I'll suggest to separate the things a bit. Keep your backend independent and create an REST API which provides the data. Once this is done you may use simply http request to access the data. By following this approach you will be later able to use other frameworks or even other languages to get the information stored into your database.
Mixing client-side and server-side composition of content can be optimized in a broad sense if your infrastructure includes reverse proxies and such. I am speaking very broadly here, but things with less state, and less coupling of state to quickly changing data, can be moved closer to the edge of infrastructure and cached and vended to clients calling http "on their own." An example might be this hour's set of suggested products for a user profile independent of the actual buying that a customer is performing. The closer you get to data and activity that is bespoke to the user and very transactional in nature, the more you need to go deep to the server side to ensure information archtecture consistency.
There's really no need to use any kind of serverside html rendering when using Angular; just serve some old skool plain html files on any webserver and grab your data using $resource or $http. It's lightning fast -- there's no faster way than only transferring the essential data to the browser.
Besides, serverside rendering is soooooo 2012