We need a restful backend that provides APIs for a mobile app.
We also need a admin website to manage the restful backend.
Right now we have Sails.js as the backend framework, Vue.js as the frontend framework.
I m pretty new to MVC frameworks and I am a little bit confused how should these two frameworks interact with each other:
Should:
The frontend framework lives indepedently (maybe on a separate server), it calls api exposed by the backend framework, or
The frontend framework lives INSIDE the Sails.js, acting as the "views" for the Sails framework
I am not even 100% sure is my question a valid question, I want to know which are the popular ways and is there any pros and cons?
You can do both i.e. keep frontend framework in Sails project as well as separate independent project.
I have done both and I keep following points in mind while making this decision:
If the project is complex enough then its better to create a separate project using some scaffolding tool.
If the project is going to change frequently and evolve on its own then also its better to create a separate project.
If some one time/small view is to be made then I would prefer to keep it part of Sails project
Since you are using frontend framework for admin panel which I think
will be complex, I would recommend you to create separate project on the same server.
You can use yeoman for scaffolding. I have used it for some angular projects and it works great.
Your question is too wide for a single explanation, but the main concept is as per my understanding is data binding.
You can find a lot of free screencasts for starting from scratch, assuming you already know some JavaScript.
Related
I'm new to building APIs, I made the first one using an MVC framework: codeigniter, with chris kacerguis rest implementation.
I'm not really sure this was the best think to do because I believe maybe the framework is not that "slim" or light just to API's purposes.
I plan to do a mobile App, an admin and a website so the three can consume the Api's services.
Is it a bad idea to have the API, the website and the admin on the same project? which are the pros and cons? or the best architectural approach?
Otherwise I will have: One Codeigniter project for the API and Another Codeigniter project for website and admin
thanks
You can create folders in "controllers" folder to organize your project and use the same project/env configuration :
controllers/Home.php
controllers/api/MyApi.php
controllers/admin/Admin.php
Edit : You will share models and libraries too.
In my project I realized 2 types of controller - REST and API. Admin js gui work with REST, other world work with API. You can do it simply with silex framework, a little brother of symfony.
The purpose of building a REST API so that you only have to build one project for your business model. This allows you to construct any number of applications on any platform, only requiring you to consume the API in different ways. This essentially separates/decouples the user interface from the business logic, and vice versa.
You should create separate projects for the REST API and each UI project should also be separated projects. This allows you to change the underlying code, language and platform in any one of the projects without breaking any of the other projects as long as the API signatures remain the same.
For example, you could have a live version of your website built using Codeignitor while developing another septate project using AngularJS. When your AngularJS project is complete you would simply swap out the project on your server (or create an entirely new website or server) still allowing you to use the other if required. Additionally, you may decide that you would like to move the API onto a different platform, language or database, develope it and swap the implementation when finished causing no changes to any of your UI projects assuming you have not changed the API signatures.
I am somewhat new to the domain of web development. I am investigating Play2 and am trying to understand, do you need some kind of JS frontend framework to go with Play2 and Scala?
I notice that Play2 has a template engine, but it seems that it generates the HTML on the server and sends it to the browser. Does this mean that the need for a JS frontend like Angular2 is made irrelevant? Or is there still a reason to use Angular2 in a Play2 application? What instances would it make sense and why?
I have some experience of using Play 2 with AngularJS (currently rewriting frontend to Angular2).
I use Play 2 (scala) only for RESTful JSON backend, which is just great for this purpose and I use Angular for single page application frontend. I find this combination brilliant.
My project is hosted on GitHub, you can check it out here
There are three directories in the root:
restful with all backend stuff, written in scala, using Slick for DB,
taking advantage of Play evolutions and all other stuff.
angularjs-client-deprecated with AngularJS code. I used angular-resource for making calls to backend.
client with Angular2 code. There is nothing there so far except for my experiments, however I've written a simple service for authentication with security token.
To summarise, I've been developing my project for almost 2 months so far, mainly to learn both Scala and AngularJS (now Angular2).
If you're planning to use JS framework for frontend, I would recommend you to use Play2 only for RESTFul Json backend. I don't see a reason to use Play2 html template engine in this case.
Play is more about Server Side templating, which isn't all that useful if you're using Angular. It can be done, but it comes with some overhead. I've worked with Scalatra in the past and it worked really well for me.
http://scalatra.org/
Other options include Spray, which is very similar from the outside, but uses Akka internally and uses non-blocking I/O, similar to Play!
http://spray.io/
With angular it is better to go with simple rest/http api like Akka-IO or spray for data and other stuff. Play will be less relevant with Angular.
As others have pointed out Play2 isn't really the best option for building responsive websites. I have a seed project which can help you get started with Akka Http and Angular 5...already configured to deploy to Heroku in a single web dyno.
https://github.com/jdschmitt/akka-angular-heroku
Check it out. I hope it helps anyone landing here looking for a way to manage back-end and front-end in a single repo for simple projects.
So we are focusing on developing a enterprise web application that utilized DDD patterns with CQRS+ES. We have a pretty good handle on that from the enterprise level. Now when we want to open up our backend services to native mobile devices using Xamarin and portable class libraries how does this come together? Do we change our domain projects in each of our bounded context to be a PCL project type? What do we do with the MVVM side of things for instance in Windows Store App, Windows Phone app? Since we are pulling from a Web API service do we pull in the PCL bounded context library or do we make a subset domain model and a separate PCL library for our native client MVVM patterns?
Right now we are leaning towards leaving the original DDD projects as class libraries and just creating a separate portable class library for our MVVM code. We will probably use file linking to link back into the domain projects to get the models so that we always have the latest set of POCO objects and any DTO objects we want to use on the client. Any one else have any thoughts or ideas on this? I really don't see a lot of discussions around this DDD+PCL combination.
I have done a lot of thinking about this and what i did to put Xamarin in my current architecture with DDD approach was:
Put your Domain Entities in a PCL project and use it to reference in all projects that you need, such as Xamarin.Forms, Xamarin.Android, Xamarin.iOS, ASP.NET, WCF, etc.
Your Domain Services can be in a normal class library that will be used for the Application layer. The application layer will be used by the Presentation projects such as ASP.NET MVC.
In the Distributed Services layer you're going to expose your services for Xamarin or other apps to communicate with your application. You can use ASP.NET Web Api or WCF with REST. This layer will also use the application layer respecting the DDD concepts.
The xamarin projects go in the presentation layer but do not use application layer. Here you will write your services for Xamarin to connect to your Distributed Services Layer through the internet. If you need offline sync you can also put that in here. Here you're going to reference your Domain Entities Project and have all your entities with their business rules.
This way you have your domain and business rules shared with all your solution and respecting DDD concepts and role separation.
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 looking for a robust REST framework to eliminate all that boilerplate code with starting up a new REST-only web service (mobile clients). Is there a framework that already has this built-in where I could, for example, simply build the domain models and run with it? I would like to see:
Authentication & User Model
Logging
Basic CRUD
Permissions (for model access)
Scalability
It seems every web service at a minimum needs the above capabilities. Somebody, somewhere must have written a good re-usable framework with the above capabilities. Any ideas? I would prefer Node.js, Java or even hosting with a PaaS service provider that offers these features.
Spring 3 MVC provides a very nice and simple annotation based framework for REST.
See http://blog.springsource.org/2009/03/08/rest-in-spring-3-mvc/ it can be deployed on any java web server like Jetty or Tomcat.
A framework like XAP provides a combined solution of Spring and Jetty plus it's built for dynamic scaling.
See http://www.gigaspaces.com/xap.
Last if you want to easily on board this solution on any cloud CloudifySource provides an open source project which includes XAP capabilities and PaaS.
See http://www.cloudifysource.org
I use Symfony 1.4 for this. It is an PHP framework. It generates most of what you need for free. The database stuff is also quite easy as the Symfony uses ORM libraries (you can choose but I can recommend Doctrine: http://www.doctrine-project.org/).
For example the whole backend site(admin) generating is a matter of running one command. They have a great e-book fro free. More info here:http://www.symfony-project.org/.
There is also Symfony 2.X (http://symfony.com/), which have a lot of new features (e.g. new Doctrine 2.0). Especially with the bundle (plugin) https://github.com/FriendsOfSymfony/FOSRestBundle is the RESTful service quite easy.