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 5 years ago.
Improve this question
I apologize if this question is too open ended. But I am struggling to get some of the principles to get started diving into this.
I am planning to build a fairly small demo app out of this seed (based on Angular 2): https://vmware.github.io/clarity/get-started
I'd like to render in an Angular UI some basic data that I keep in a back-end Redis database.
I am trying to find out what application layer I should be using to sit in between Redis and the Angular UI.
I am currently thinking of either using Ruby (just because I am slightly familiar with it) or Node.js.
Part of my struggling is because I am confused about the relation between Node.js and Angular 2 and I am wondering whether using Node code can help me integrating better and more easily with Angular (than with Ruby).
Other than using the same language/syntax (js), I have the gut feeling that I could more easily run a Node "app.js" file with some trivial business logic that reads from Redis and pass the result onto the Angular application. At least I could run the app.js logic on the same http instance where I am running the Angular application (my assumption).
If I wanted to use Ruby I have to use some web framework (e.g. Rails or Sinatra) to serve requests coming from the Angular application (e.g. in Angular I will have to make calls to http://myrubysrv/applogic).
Other than the language and this deployment detail, I am just wondering if passing variable from the application logic component into the Angular application is going to be easier if I use Node or the level of effort is going to be exactly the same whether I use Node or Ruby.
Thanks.
You do have some options here. Angular 2+ apps compile to what is essentially just an index.html that will handle the loading of other necessary views. So, you just need something that is able to serve an index.html file, and your application API could live completely separate from your serving application. Depending on how you're hosting, you have a lot of options here (for example, GitHub pages hosting your frontend and your backend on Heroku.
Rails makes setting up an API-only application a breeze and works quite well with Redis. I would say it's definitely the easiest option here; if you do need to pass in environment-specific configs to the Angular app, there are ways to do this while bootstrapping the startup.
Node is always a good option, but I've never worked with Node-Redis so I couldn't tell you the hangups. I can also say that Rails would likely be easier.
However, Angular Universal primarily supports Node, with the only other supported platform being .NET. If you want to use or mess with Universal (super cool stuff) Node would be needed, at least when serving the app.
Node would also offer a chance to brush up on your Typescript chops outside of Angular, if you are looking for a learning opportunity.
Angular is agnostic to the backend you use. Just expose a REST endpoint either from your RUby or Node+Expres backend. The client will use something like this anyway:
http.get("/products").subscribe(...)
Take a look at these code samples where Angular talks to Node:
https://github.com/Farata/angular2typescript/tree/master/Angular4/http-node-samples
Related
After coding for a couple of years, I have implemented many different software services into applications I was coding, using API documentation that software owner has provided. And I thought that was all about APIs I need to know, that it's just a way to make to software services communicate with each other.
But now I got a task to create an application, I wont go into detail, but let's say it just needs to implement CRUD operations and that it should use Vue on front and Laravel on back. And in the explanation of a task it is mentioned that I should use REST API for triggering those operations. And that's the part that confuses me!
Since I have never created an application from scratch, I was only working on already stable applications, fixing bugs and implementing new functionalities (and I guess this is the what it looks like for the most of the people who work in big companies today), and that's why I thought that those two frameworks (Vue and Laravel) have already implemented REST APIs since they can communicate between themselves.
Why am I specifically asked to use REST API to trigger those operations? Is there any way other than using an API to make front communicate with back (even I am using frameworks already)? If not, do they want me to create my REST API for communication and not use the one that is already provided by frameworks? I am confused, why did they mention to use REST API as if it wasn't default option, something that shouldn't even even be questionable, just an expected behavior.
why did they mention to use REST API as if it wasn't default option
For many years, offering an API in the backend for JS frontend consumption was not the default option. Traditional "round trip" applications use a form that submits to the server with a full page refresh, and I'd hazard a guess that most web applications live today still work like that.
With the advent of Vue, React, Angular etc, there is an expectation that fetching data and sending data is done via APIs in an AJAX operation. This gives applications a more seamless feel, and they're faster, since only a relatively small amount of data needs to be sent or received.
In small Laravel/Vue applications, the frontend and backend are often in the same repo, and are deployed together as a single unit. However, as the size and complexity of an application increases, there is value in splitting up these pieces into microservices, which can be deployed separately, without tricky system dependencies complicating the deployment pipeline and sign-off process. Using an API lends itself well to that approach.
Indeed, as the backend increases, the API is not one service, but several, split by process area (e.g. user, sign-up, checkout, dashboard, etc).
Do Laravel and Vue always use ... APIs to communicate?
So, to answer your main question, you don't have to use APIs/AJAX with Vue and Laravel. You can still use standard HTTP forms and redraw the whole screen if you want.
Do Laravel and Vue always use RESTful APIs to communicate? [my emphasis]
Another way of interpreting the question is that perhaps you have received instructions from someone who was differentiating a REST API from a different kind of API. On the web, GraphQL is becoming more popular. Server-to-server, SOAP (XML) used to be very common, and is still in use in many enterprises.
FOA, The gap is not going to fill "ASAP" because it requires domain knowledge that you are missing. And yes RESTful API is the best way unless you want multi-dimensional communication across multiple platforms.
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 6 years ago.
Improve this question
I'm learning Spring Framework. So I want to build the application which architecture will be good enough. For example my application will be some kind of a social network. I'm using Spring Boot container for this web application.
Is this architecture is correct? I mean scalability, future code support, etc. What are advantages and disadvantages? I want to use REST api and microservices. 1 page = 1 controller = 1 service.
1 service, 1 controller, 1 page is not a good thing to limit yourself to. You'll find a page may use a whole bunch of different services. Imagine if your facebook profile was one controller. It would be gigantically large, impossible to maintain. Just break downs things as logically as you can. Sometimes it may make sense to have a page which uses multiple controllers, sometimes you could have a controller which handles multiple pages so you don't have 30 really small controllers. I would say if you have a complex page you'll need multiple controllers, if you have allot of very simple pages one controller may handle many of them.
Can I also suggest you don't break things up when you don't need to. All your micro services your planing can just be components in your application. Otherwise you will find you have a massive overhead of maintaining code which just forwards and receives HTTP requests. This could also cost you an extremely valuable tool: Transactions! You will lose transactions, and this could lead to inconsistencies in maintaining data. Keep in mind your just one person. I have been trying to finish a webapp I have been working on which is 95% done and I'm spending 8 hours a day after work, working on it till 2am. Do your self a favor and don't create more work for yourself.
I agree with most points of Snickers3192's answer. Microservices is not something you should plan up front, your application should exist first, a monolith is fine for the beginning. Martin Fowler has written a good piece about the Microservices yes or no question. Once your app grows and you see the need for either parts of your application being scaled separately or teams needing to be able to develop independently, then you've got a business case for Microservices (and as you'll see from Fowler's article, you must also be ready to support such an architecture). Right now it's overengineering.
That said: If you start with a monolith and plan to evolve to Microservices later, then you need to pay attention to your dependency tree. Different parts of your application will need to access each other, and that's fine, but make sure you don't introduce circular dependencies, otherwise extracting Microservices later will be a nightmare. Ideally, you can identify service interfaces that you will use, and you implement them locally now, but may later implement them by calling a Rest API.
The pattern you suggest (1 service for 1 controller) maps to the Backends for Frontends pattern, which can be a good idea, depending on how complex your web site is. If you have many UI components that are shared between controllers, then you'll probably want to embrace another approach, e.g. Big Pipe. But it does make sense to have one controller that bundles everything a given page needs to know and delegates it to the upstream services, independent of whether all of this is on the same machine or in a Microservice architecture.
Lastly: if you do go with Microservices, pay attention to resilience. Use a circuit breaker like Hystrix or an event-driven architecture, otherwise one dying service can take down the entire architecture.
I am trying to integrate spring-mvc and reactjs, but it's too poor example, but I like flux architect of reactjs so that i strongly want to integrate reactjs with springmvc!
I want to use reactjs as a client side, springmvc as a rest backend. Can you provide me some example or tutorial to do this? I've searched on google but it's very poor result. Please help me.
Thanks you very much
This answer might not be what you want, but I would advise you not to integrate the two of them. If they communicate over HTTP/WebSockets, they are already decoupled, and it might just cause you pain to couple them.
Advantages of decoupling the frontend and backend into separate projects:
People with experience only in React or Spring can contribute without getting confused by the other stuff.
The tooling/build you need for a Spring project is quite different from what you need for a frontend project, and mixing this into one code base can get pretty confusing.
If they're decoupled from the start, it gets easier to add other clients that use the backend API. By having them as separate projects, you're less likely to develop the backend in a way that's very tied to the frontend.
The frontend and the backend should use different versions and be shippable independently of each other. What if the backend team is currently doing a major refactoring, but the frontend team just fixed a critical bug and wants to ship a new release?
As soon as you add asset caching to your frontend project (like putting the files on a CDN, using the HTML5 application cache or the new Service Worker API), you have to prepared for getting requests to your backend from "old" clients. By separating them, it's easier to think about and plan for stuff like that on the backend.
I could probably list a couple of more benefits, but these are the ones I consider has the largest impact. There are of course some benefits of integrating the two of them, but those tend to get smaller and smaller as the project grows/matures.
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 8 years ago.
Improve this question
I'm working on a Web application that I decoupled it in multiple containerized microservices. I have now around 20 services, but the whole system will definitely need more than 300. Most of the services now and some in the future will not need an entire machine so I'll deploy multiple services on a same host. I'm wondering how others deal with interservice communication. My preferred way was to go with a REST based communication but...
Isn't it too heavy to have multiple web servers running on the same machine? I'm developing in Ruby, but even a lightweight web server like Puma can consume a good amount of memory
I started writing a custom communication channel using UNIX sockets. So, I'd start one web server and my "router" app would communicate with the currently running services on that host through UNIX sockets. But I don't know if it's worth the effort and on top of that, all services have to be written and customized to use this kind of communication. I believe it would be hard to use any framework like Ruby-on-Rails or others, even different languages which is the whole appeal with microservices architecture. I feel like I'm trying to reinventing the wheel.
So, can someone suggest a better approach or vote for one of my current ones?
I appreciate any help,
Thanks,
Looks like you may want to look into docker swarm, they're actively working on these use cases. I wouldn't recommend building your own communication channel, stick with http or maybe use spdy if you're really concerned about performance. Anything you introduce will make using these upcoming solutions more difficult. Also keep in mind you don't need a heavy-duty web server in most cases, you can always introduce a layer above one or more of your services using nginx or haproxy for example.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I would like to use Node.js to develop a website. I've seen a lot of frameworks here: https://github.com/joyent/node/wiki/modules#web-frameworks-micro but do not know which one is the most accepted by the community (let's say: the most popular). Did anyone tried any of these frameworks and/or used it in production and what is your experience? Thanks.
Express.js seems to very popular to use as a general framework. Combined with socketio.js and underscore.js these are very popular libraries but they are not MVC.
For MVC I've only used backbone.js / spine.js and can't give any recommendation for the others. I don't think there is a framework with a dominating popularity going yet because node.js doesn't have much use in production.
There are statistics for popular downloads with npm somewhere. See if you can find them.
Another great MVC framework that is up and coming is Sails.JS. It is inspired by ruby on rails and has features such as socket support, Restful API and more.
http://www.sailsjs.com/
Try RailwayJS. CompoundJS
RailwayJS seems to have been killed and replaced with CompoundJS.
There's a guide for anyone that started with Railway and wants to migrate to Compound.
I just released Locomotive, which is an MVC framework inspired by Ruby on Rails.
Express is phenomenal, especially for smaller apps. Recognizing that, Locomotive is built completely on top of Express (similar to how Express builds on top of Connect). Locomotive essentially adds a controller layer along with a router that can declare resourceful routes and generates routing helper functions. Internally, everything is powered by Express, which means the view layer remains the same and all middleware can be reused.
One of the bigger hurdles when learning Node is figuring out how to best structure a web application. Locomotive attempts to solve that problem, using conventions from Ruby on Rails, while retaining the full power of Express and Node.
There is matador. It is MVC and it consists of many different existing components, such as Klass for inheritance model, express, hogan.js, and valentine. Backbone.js is pretty much used for client side. For node, i think there's probably only matador that I know.
I'd suggest you against using it if you're to use matador for production or replace your existing MVC platform (or at least have a bottleneck/good reason to use it) since it's pretty new, and your productivity also depends on the javascript resources you have. We ourselves use node.js very extensively (our node.js deployment serves close to +4 Million users to date) and we have a significant number of javascript specialists here..so we experiment a lot and probably look into using matador soon. Hope that helps.
Geddy was the original MVC framework for Nodejs, check out http://geddyjs.org if you're interested.
Just came across a new one called Derby which looks like it has a lot of promise. Its main benefit seems to be that it cuts down on a lot of the "glue code" (as they put it) that we often write when trying to use rails and backbone, or django and backbone together. The documentation seems pretty decent for a node framework as well.
Monorail.js - Ultra lightweight MVC Framework for Node.js
https://github.com/runexec/Monorail.js
There are a few more frameworks which you could check:
ThinkJS https://thinkjs.org/ the first Node.js MVC framework that can use full ES6/7 features to develop Node.js application.
Feathers http://feathersjs.com/ a minimalist real-time framework.
Meteor https://www.meteor.com/
Keystone.js http://keystonejs.com/ built on Express and MongoDB (MIT license).
seneca.js http://senecajs.org/ Everything external to a business logic - such as databases, caches and third-party integrations - is hidden behind microservices.
Catberry http://catberry.org/ was developed to help create apps that use the same codebase on both the server and client environments to render what the client would see as a "Single Page Application".
Nuke.js http://nukejs.com/#/ Fast framework. The stack contains primus, express, mithril, mongodb and redis
Hapi.js http://hapijs.com/ rich web application server framework for Node.js.
total.js https://www.totaljs.com/ The framework contains full web server, view engine, SMTP mail sender, localization, image processing, websockets, isomorphic code and a lot of utilities