I've been getting into isomorphic applications development with Angular 2 Universal but there is this thing that i cannot get clear in my head.
My understanding is that keeping back and front sides on different modules is a good practice, but it doesn't seem to be a common pattern when working with MEAN applications.
So, i am about to start a project that could scale and i'd want to implement the server side rendering in a future but i don't know which approach i should go with. Honestly i feel more comfortable keeping both backend and frontend on separate but, if so, will it be possible to implement server-side rendering later on?
Besides, supposing that i duplicate the index.html in both sides, will the server be able to delegate the control to the client when the first server rendering is completed? I mean, i can't imagine how that would that delegation work given the fact that they are not in the same project.
Thanks in advance.
As I understand, you are talking about rendering the UI and this is frontend part of your application, even if you do the pre-rendering work on the server.
This pre-rendering is only optimization, you can keep it in some separate code layer, but I believe that the whole idea of the isomorphic javascript is to re-use the same code on the client and server. This way trying to duplicate code and/or templates is not a good idea (it never is).
If you really want to keep things separated, think on splitting your application into more services:
backend server application - some kind of rest API on top of the database which holds all the business logic (first node.js application)
frontend server application - another node.js application which gets data from API via HTTP requests and does server-side pre-rendering (second node.js application)
frontend - all the code running in browser
This way, initially the "frontend server application" can be simple proxy between the "frontend" and "backend server application".
Later on you can extend it with server-side rendering.
Important note: if you are going to develop application without pre-rendering on the server and add this on a later stage, you need to take into account that not all the browser-side javascript features will work on the server (for example, manipulations with native DOM elements), see the best practices section in angular universal readme.
Related
I have an asp.net website project that uses APIs as a back-end, i need to totally decouple my front-end from my back-end apis, so I have created one RESTful service in my back-end project and now i want to consume it in the front-end. I assume i have two solutions:
Build my model only in the back-end, and add reference to the front-end, to avoid re-writing the same model in the front-end again. (Coupled)
Build two exact models in both back-end and front-end. (Decoupled)
Pros:
Solution 1)
Avoids re-writing the same model in the front-end again.
Forces updating front-end model once back-end changes (otherwise build error)
Solution 2)
Helps decoupling my front-end from the back-end.
Will avoid build errors if back-end model changes. (Front-end exceptions)
Please advise which approach is better design, and if you have suggestions please share.
This depends on your speed of change for both backend and front-end and how well your tooling supports it, but there is a reason why in most cases people just use two models.
(That reason is that it is very hard to get this right and it reduces your agility enormously.)
Usually you will not want the same model in the front-end as in the back-end:
Decoupling is good. There's no reason to have your front end coupled in any way to your back end.
Your data is naturally structured differently in the front end vs. the back end.
You may eventually have multiple front-end apps using the same back end.
A particular front-end may consume a different (set of) back ends
I developed a REST API with go (golang), and now I want to design my web frontend. I don't know how can I separate frontend from backend.
I think that I have three choices:
1- Run REST API on one server and the frontend website on another server.
2- Run REST API and frontend website on the same server, but on different ports. For example run REST on port 8080 and frontend website on port 80.
3- Run Both on the same server and the same port, but use different URL paths (or subdomains) for each one.
As I don't know about this stuff, please tell me which one is true or best solution. Or is there any other solution? Does it matter how big my website is?
Either the first or second options will be mostly the same for you to set up and develop with. So you don't lose or gain anything from that perspective, the only deciding factor is your resources and how you expect your backend to be used in the future.
Currently, if you only have one application/frontend calling on the API, having them be on the same server will be the better option since it will have a marginally increased performance compared to the second option.
But, since you chose a RESTful design for your backend, you might want to reuse it for more applications in the future, and if you expect that the increase in calls to the API will start to use up the server resources, then your frontend might suffer from it and then you should consider relocating the backend to a different server.
The whole microservices, RESTful backend design "pattern" was created to decouple the front and back for better scaling, but that might not be necessary for everyone, you have to estimate the amount of use your application will realistically have and think if you might actually reuse the API elsewhere (or if you want to offer the API for others or not).
In the end, if the first and second option present a similar amount of investment for you at the moment, go for the first one, if not, just keep both front and back on the same server and if in the future you realize you need to scale out, you can just relocate the API to a different server/servers.
Let's suppose I was going to design a platform like Airbnb. They have a website as well as native apps on various mobile platforms.
I've been researching app design, and from what I've gathered, the most effective way to do this is to build an API for the back-end, like a REST API using something like node.js, and SQL or mongoDB. The font-end would then be developed natively on each platform which makes calls to the API endpoints to display and update data. This design sounds like it works great for mobile development, but what would be the best way to construct a website that uses the same API?
There are three approaches I can think of:
Use something completely client-side like AangularJS to create a single-page application front end which ties directly into the REST API back-end. This seems OK, but I don't really like the idea of a single-page application and would prefer a more traditional approach
Create a normal web application (in PHP, python, node.js, etc), but rather than tying the data to a typical back end like mySQL, it would basically act as an interface to the REST API. For example when you visit www.example.com/video/3 the server would then call the corresponding REST endpoint (ie api.example.com/video/3/show) and render the HTML for the user. This seems like kind of a messy approach, especially since most web frameworks are designed to work with a SQL backend.
Tie the web interface in directly in with the REST api. For example, The endpoint example.com/video/3/show can return both html or json depending on the HTTP headers. The advantage is that you can share most of your code, however the code would become more complex and you can't decouple your web interface from the API.
What is the best approach for this situation? Do you choose to completely decouple the web application from the REST API? If so, how do you elegantly interface between the two? Or do you choose to merge the REST API and web interface into one code base?
It's a usually a prefered way but one should have a good command of SPA.
Adds a redundant layer from performance perspective. You will basically make twice more requests all the time.
This might work with super simple UI, when it's just a matter of serializing your REST API result into different formats but I believe you want rich UI and going this way will be a nightmare from both implementation and maintainance perspective.
SUGGESTED SOLUTION:
Extract your core logic. Put it into a separate project/assembly and reuse it both in your REST API and UI. This way you will be able to reuse the business logic which is the same both for UI and REST API and keep the representation stuff separately which is different for UI and REST API.
Hope it helps!
Both the first and the second option seem reasonable to me, in the sense that there are certain advantages in decoupling the backend API from the clients (including your web site). For example, you could have dedicated teams per each project, if there's a bug on the web/api you'd only have to release that project, and not both.
Say you're going public with your API. If you're releasing a version that breaks backwards compatibility, with a decoupled web app you'd be able to detect that earlier (say staging environment, given you're developing both in-house). However, if they were tightly coupled they'd probably work just fine, and you'll find out you've broken the other clients only once you release in production.
I would say the first option is preferable one as a generic approach. SPA first load delay problem can be resolved with server side rendering technique.
For second option you will have to face scalability, cpu performance, user session(not on rest api of course because should be stateless), caching issues both on your rest api services and normal website node instances (maybe caching not in all the cases). In most of the cases this intermediate backend layer is just unnecessary, there is not any technical limitation for doing all the stuff in the recent versions of browsers.
The third option violates the separation of concerns, in your case presentational from data models/bussines logic.
I own a Play 2.1 application.
Initially, I used the default template mechanisms from Play 2.1 until I .. learned AngularJS.
Now, I clearly want my client side to be an AngularJS app.
However, while surfing the net, I find there are no clear way to achieve it:
Letting Play behave as a simple RESTful application (deleting the view folder) and making a totally distinct project to build the view (AngularJS app initialized by grunt.js).
Advantage: Likely to be less messy, and front and backend teams would work easily separately.
Drawback: Need another HTTP server for the AngularJS app.
Try to totally integrate AngularJS app with the traditional Play's workflow.
Drawback: With a pretty complex framework like AngularJS, it would lead to a confusion of templates managementfor instance : scala.html (for Play) / tpl.html (for Angular) ... => messy.
Making a custom folder within the play project but distinct from the initial folders created by the Play scaffolding. Let's call it myangularview instead of traditional view for instance. Then, publish static contents generated by grunt.js into the Play's public folder, in order to be reachable from browser through Play's routing.
Advantage: SRP between components is still fairly respected and no need to use another light HTTP server for the client-side like in 1.
I pointed out my own views of advantage and drawbacks.
What would be a great way to achieve the combination of Play with Angular?
Yes, I'm answering to my own question :)
I came across this way of doing:
http://jeff.konowit.ch/posts/yeoman-rails-angular/
Rails?? No matter the framework is, the need remains exactly same.
It advocates a real separation between APIs (backend side), and front-end side (in this case making AJAX calls to backend server).
Thus, what I've learned is:
During development phase, a developer would use two servers: localhost on two distinct ports.
During production phase, the front-end elements would be encompassed into the whole backend side (the article would deal with a kind public folder, aiming to serve static contents: HTML, angular templates (for instance), CSS etc... Advantage? => dealing with a one and unique serving server's APIs exposition as well as static assets for the UI.
With this organization, some tools like Yeoman would be able to bring some really awesome handy things to developers like for instance: the livereload feature. :):)
Of course, during development phase, we end up with two different domains, (localhost:3000 and localhost:9000 for instance) causing issues for traditional ajax requests. Then, as the article points out, a proxy may be really useful.
I really find this whole practice very elegant and pleasant to work with.
There was an interesting discussion on the play mailinglist a couple of days ago about frontend-stack/solution, could be something in it for you, quite some people using angular it seems: https://groups.google.com/forum/#!searchin/play-framework/frontend/play-framework/IKdOowvRH0s/tQsD9zp--5oJ
I am working on a experimental website (which is accessible through web browser) that will act as a front-end to a restful interface (a sub-system). The website will serve as an interface between a user and the restful interface, as it will make http requests to the restful interface for almost all database operations. Authentication will probably be done using openid and authorization for the database operations will be done via oAuth.
Just out of curiousity, is this a feasible solution or I should develop two systems that accesses the database in parallel (i.e. the website has its own data access logic, and the restful interface has another data access logic)? And what are the pros/cons if I insist on doing it this way (it is just an experiment project for me to learn things like how OpenID and oAuth work in real life anyway) besides there will be more database queries and http requests generated for each transaction?
Your concept sounds quite feasible. I'd say that you'll get some fairly good wins out of this approach. For starters you'll get a large degree of code reuse since you'll be able to put other front ends on top of the RESTful service. Additionally, you'll be able to unit test this architecture with relative ease. Finally, you'll be able to give 3rd party developers access to the same API that you use (subject possibly to some restrictions) which will be a huge win when it comes to attracting customers and developers to your platform.
On the down side, depending on how you structure your back end you could run into the standard problem of granularity. Too much granularity and you'll end up making lots of connections for very little amounts of data. Too little and you'll get more data than you need in some cases. As for security, you should be able to lock down the back end so that requests can only be made under certain conditions: requests contain an authorization token, api key, etc.
Sounds good, but I'd recommend that you do this only if you plan to open up the restful API for other UI's to use, or simply to learn something cool. Support HTML XML and JSON for the interface.
Otherwise, use a great MVC framework instead (asp.net MVC, rails, cakephp). You'll end up with the same basic result but you'll be "strongerly" typed to the database.
with a modern javascript library your approach is quite straightforward.
ExtJS now has always had Ajax support, but it is now able to do this via a REST interface.
So, your ExtJS user interface components populate receive a URL. They populate themselves via a GET to the URL, and store update via POST to the URL.
This has worked really well on a project I'm currently working on. By applying RESTful principles there's an almost clinical separation between the front & backends - meaning it would be trivial undertaking to replace other. Plus, the API barely needs documenting, since it's an implementation of an existing mature standard.
Good luck,
Ian
woow! A question from 2009! And it's funny to read the answers. Many people seem to disagree with the web services approach and JS front end - which has nowadays become kind of standard, known as Single Page Applications..
I think the general approach you outline is quite feasible -- the main pro is flexibility, the main con is that it won't protect clueless users against their own ((expletive deleted)) abuses. As most users are likely to be clueless, this isn't feasible for mass consumption... but, it's fine for really leet users!-)
So to clarify, you want to have your web UI call into your web service, which in turn calls into the database?
This is exactly the path I took for a recent project and I think it was a mistake because you end up creating a lot of extra work. Here's why:
When you are coding your web service, you will create a library to wrap database calls, which is typical. No problem there.
But then when you code your web UI, you will end up creating another library to wrap calls into the REST interface... because otherwise it will get cumbersome making all the raw HTTP calls.
So you essentially created 2 data access libraries, one to wrap DB and the other to wrap the Web service calls. This basically doubles the amount of work you do, because for every operation on a resource, you will end up implementing in both libraries. This gets tiring real fast.
The simpler alternative is to create a single library that wraps access to the database, as before, then use that library from BOTH the web UI and web service.
This is assuming that your web UI and web service reside on the same network and both have direct access to the backend database server (which was the case for me). In this setup having both go directly to the database is also a lot more efficient then having the UI go through the web service.