We have a classic Rails application that we are willing to convert into an API only back-end. A Javascript framework will replace the UI portion.
At its current state, the classic application is fully based on AJAX calls, so the end user can feel that it's using a full JS Framework, but in reality it's just jQuery.
In comparison with the classic application, how the newly updated application ( API with JS UI ) will behave. I know that the server will not have to compile and serve views anymore, wich is a gain, but how much gain will I have, we are talking here about performance. Is it worth the hassle?
Use Rails as an API and have the front and backend in different applications won't have significant difference in your current performance.
Performance is something very abstract and can be improved from many point of views. your rails backend won't have to serve views, however your JS UI will have to communicate with it through the API what in performance matter means the same.
For improve your performance you need to have an optimized backend and also an optimized front-end, it does not matter if you have separate apps for serve backend and the frontend.
Check This blog post that will drive you about the rails performance. Also for those who want to convert their current apps in just backend from rails take a look to rails-api, It's basically a stripped down version of Rails (you don't need things like cookie authentication or MSIE rendering helpers in an api server).
Summary: Maximize your performance as a developer. Use stack you know best. First make it work, then make it fast, it does not matter if you separate front end from backend.
Related
What is the architecture difference between working with razor vs blazor?
Documentation suggest that I have to write an Web Api when using blazor - is it still possible to pass model objects like in traditional razor ?
0 Video with visual explanation
I decided to make a video, since several questions about Blazor were asked (also on other forums) and this format seems much better for me to visualize the differences - instead of reding my (longer) explanation. The video contains a bit improved version, compared to my first post (the text post is also updated) It's one of my first videos in this format, so any feedback is welcome. If you prefer to read a classic text without much visualization, you'll find it's content in the following sections. Of course without the demos, which I made to lighten the content up, but the basic information content is the same.
1. What is a traditional multi-page site or application?
First you need to have a basic understanding how traditional websites/apps works: For every call/request, you send a request to the server and the server responds with the complete HTML of the entire page. This can be dynamically generated like with ASP.NET Core MVC and Razor templates or Razor Pages or even some other technique like PHP, Java, Python and so on. Let's say you have a list of articles showing a preview.
To illustrate this, let's say you have a list of articles (for example blog posts) showing a preview. When the user clicks on read all, you usually have two ways to realize this in traditional web apps:
Load a page like /view-article?id=123 where the above happens again: Loading the entire HTML DOM of the article page
Using JavaScript to make an Ajax-Request, which loads the desired content from an API like /api/get-article?id=123 and manipulate the DOM to display it at the desired position
Without JavaScript, traditional sites are not interactive. This means: After the page is loaded and rendered, nothing happens any more – except the user load another page (with the entire DOM) by clicking on a link – for that reason, it’s called „multi-page“ application.
You'll propably prefer the second approach, cause it's faster and saves ressources: Instead of rendering the entire page again (where only a part of it has changed), you stay on that page and just load the new information you need (the article content in this example). Especially on large pages with many ressources to load and render, the JavaScript approach feels much faster to the user.
If you like traditional pages to be interactive, you need JavaScript. For example you can add an ajax call to some API that displays some data when the user clicks a button, without having to reload the entire page.
In short we can say, that most of the work happens here on the server side.
2. Where is the difference to single-page applications (SPA)?
SPAs have just a single page, in terms of a full rendered html page. If you navigate there like by clicking on article, they load a JavaScript application. It handles everything interactive there. If the user clicks on an article, there is NO complete HTML document fetched from the server! Instead, it only fetches the parts who are changed, in this case the article. Everything else (e.g. navigation bar, footer, widgets etc) will remain - in opposite th multi-page apps, where this may be reloaded if no js/ajax is used.
You often have modulary components there and two-way data binding. This means, a variable is linked to some HTML element. When the variable changes, the element automatically displays the new value. In traditional apps, you'd have to create event handlers manually to handle this. It can be seen as continued development of a single page application with vanilla JavaScript, where you need more manual work to archive things like data-binding.
For the user, a SPA normally is much faster than navigating through pages on multi-page apps.
In short we can say, that most of the work happens here on the client side in the browser of the user. The server just serves static stuff (html, js, css) and provides APIs for e.g. fetching entries from the DB or save them.
3. What has Blazor to do with that?
A Blazor app actually is a SPA. But the main difference to other frameworks is, that Blazor lets you control both the client and server side with C# code. To show that benefit, let's look at other SPA frameworks like Angular: You can build an Angular SPA with ASP.NET Core. In this case, you write your client side in Angular with TypeScript. If you need to access data, it will make API calls to the ASP.NET Core server, which is C#. It will be similar with other frameworks like React, but here with JavaScript instead of TypeScript.
This make it hard to share code between those two: If you have an article model, it needs to be defined in C# on the server and in TypeScript on the client as well. With Blazor you just define it once in C# and re-use it on both sites. In other words: You just write C# without having to care about JavaScript*
*That’s the basic idea behind Blazor: Use C# everywhere, without the need for JavaScript as second technology. But it’s worth mentioning that you need to work with Blazor components to accomplish this. If you need some library not being ported to Blazor yet, you still have to handle a bit of JS. However, there are still benefits like the data binding. Using it on an entire plain JS stack would be some work, so I’d recommend to start with an UI library that offers Blazor components.
3.1 Blazor WebAssembly and Blazor Server
Now you know the basics and you need to decide between two flavours:
Blazor WebAssembly
As the name suggests, it basically uses WebAssembly to run your C# browser directly in the browser. It requires a relatively recent Browser and is not yet supported on all platforms/browsers. Also major engines like Chromium or Safari doesn't support all standardized features yet.
Let's say you have a button with C# code as handler like this:
<button class="btn btn-primary" #onclick="IncrementCount">Click me</button>
IncrementCount is a C# method. The code got transfered to the client and would be executed in the browser. Imagine it as .NET Core runtime inside the browser, like Silverlight BUT without any external plugins. There is no need to even have ASP.NET Core on the server-side! It can be served from any webserver, as long as you don't need things like DBs from the server side. This makes the app larger (and slower, at least on the first load).
The example Visual Studio template has a size of more than 17 Megabyte! With compression this can be reduced to 7 Megabyte – still a lot for a hello world application. By publishing the application in release mode, this goes down to about 7 MB and 2.4 MB with gzip.
At least subsequent requests are faster. Those DLL files are stored in the browser cache, which avoids further requests.
But it can be used offline (at least the main logic without API calls). For that reason, it's sometimes called real SPA – it’s compareable to Angular, React and other client-side frameworks.
Because of the WebAssembly-Usage, Debugging can be harder here, currently it just support Chromium based browsers.
Don’t know WebAssembly? It’s a relatively new, open standard that generates bytecode to improve loading and execution time to realize more powerfull web-applications – independent of the language. You’re not forced to use specific languages like JavaScript: Since Bytecode is generated, also other languages like C++ or Rust can be used.
In a nutshell, WebAssembly can be seen as next generation JavaScript for feature-rich webapps, where Blazor WebAssembly is the C# implementation. Because of the browser runtime, there are some APIs which can’t be used here. For example sockets or I/O access, like File.Open or File.Write.
Blazor Server
The app runs on the server and just transfers the output (like the result of a click event, that increases some counter in another HTML element) to the browser using SignalR Websockets. This makes the app smaller and faster, but requires more ressources on the server-side cause you have a SignalR connection and it's virtual DOM also on your server - making it harder to scale in large setups.
On the other side, this reduces the requirements on the clients: They don't need to support WASM, so it could run on older browsers or browsers with restricted WASM support as well as low-end devices. But since every action ends in a SignalR call, the app won't work offline - if this is a requirement, choose Blazor WebAssembly over Blazor Server.
What to choose?
It depends on your needs, as pointed out above. For example, if you need offline support, Blazor server wouldn't be a good choice. If you're unsure I'd prefer Blazor Server and only really worry about this if you're planning to deploy a very large application.
Imho, Blazor server is currently smoother and more flexible. Blazor Server also got stable before WebAssembly. This recommendation may changes in the future, when WebAssembly has developed further and got more widely supported.
But in this case, you can migrate later!
Both Blazor WebAssembly and Server use Razor components. This means: You can change between both, without re-writing your entire code. Some migration work is only required for things like data-calls outside the browser when migrating from Blazor Server to Blazor WebAssembly. The reason is, that Blazor WASM runs entirely in the browser, so you need a server part like an ASP.NET Core API projekt to handle them.
Further information
I recommend the Introduction to ASP.NET Core Blazor in the official documentation. Also the other chapter describing a lot of information about the platform and offers tutorials. They go deepter in detail to topics like data binding or event-handling to just name a few, and illustrating them with examples. I tried to kept it shorter here for a basic overview.
See also: Blazor WebAssembly 3.2.0 and ASP.NET Core 5
I have a project that involves both mobile and web clients. The mobile clients will mainly get content and post user updates, while the web client is mainly for creating content. As such, the web client and API share a lot of the same models and validation.
I am trying to decide the best approach in this case:
JSON-only Rails API + separate Rails web client that calls API.
Single Rails app with separation of API and client side (somehow).
The pro for me in terms of option N°1 is the separation of concerns, as I can work on the API while someone else do the web client. The con seems to be lots of duplicated code in terms of validation.
N°2 could make more sense in terms of reducing code duplication but it would get messy if more than one person is working on the same code base and setting up a process to resolve code conflicts is not something I want to do at this point since we're an early stage startup and want to get out something quickly.
Is there anything I'm missing?
The best practice is use ONE rails application for API and Web Interface
To separate those parts, just create a namespace for API like it's described there http://collectiveidea.com/blog/archives/2013/06/13/building-awesome-rails-apis-part-1/
Do it in one.
The con seems to be lots of duplicated code in terms of validation.
No, you would not have duplication the validation happens in the model, which is shared by your API <=> web controllers. Of course, you will have separate implementations for the actual authorization/session handling (if you have those), but these will not likely be duplicate but a bit different for your two access layers.
I'm looking at building a simple login-based iOS application that needs secure access to create, read, updated and delete data from a MySQL database - with certain actions available to specific users based on roles.
I've done some research and it looks like I need to build a RESTful Web service which provides Web Services which the iPhone app calls to access the data.
I have very little experience of web services development, are there any books/tutorials that are worth checking out? Is it worth looking at a web framework, rather than start from sractch?
I've done some basic web development in PHP/Python so would prefer to build in that I think..given that hosting it would be relatively cheap..
Have done some basic C#/Java; would it be worth looking at these instead? I tried creating a simple ASMX webservice but most of the examples cite using a MSSQL server, not sure if that is the way to go though.
Use a framework. No point reinventing the wheel and giving yourself a headache. A good PHP based solution would be to use Drupal to build the backend using the Services module to provide data via webservices. Drupal is so flexible and so popular now, that you can get a lot of what you want done without any code at all.
Roughly:
Install Drupal 7 on a webserver according to the instructions
Install the Services module
Design the entities that will make up your MySQL database
Tell the services module how you want to expose things
Some examples of API calls are here.
A case study of someone else who has used Drupal as the backend for iPhone/Android is here.
You will have a learning curve to get your head round Drupal, but you'll have one anyway to get your head around webservices and the benefits you gain from having everything else Drupal offers are enormous, e.g.
The difficult bits are already done for you, so the amount of code will be massively reduced, if you even need any at all
Using Drupal's hugely flexible entities system, you can design a flexible and extensible mysql database scheme using the web based UI, which will be ready to work with any of Drupal's other modules, so you can expand add features with minimal effort in the future
There's an enormous community of people who can help you and the forums on drupal.org are very active
You would have a great UI for users, in case you ever need to give them access to their data through a normal website interface. Drupal has loads of pre-built themes (I recommend Omega) which look awesome and again, little to no code is needed to get a whole site ready made along with HTML5, standards compliance etc.
Drupal provides you with ready-made modules to provide access control via roles, as well as everything else you can imagine e.g. managing a mailing list for your users, providing you with usage statistics, admin interface for user and role management etc.
Drupal use is exploding globally and there's a serious skills shortage, so you'd be even more employable :)
First, it's not compulsory that you use a REST web service. It's just that WS si more or less standard for web-based applications.
I'm not really familiar with PHP, but in python you have django-piston. On the IOS side you have restkit to pair the server with.
What I could say from my experience is that writing a prototype in django is quite easy and you can definitely use this to develop your app.
I was wondering this for quite a while and haven't really found an answer for this yet.
Why would you use Backbone.js exaclty inside a Rails application? Is it to extend functionality, have a more MVC pattern for your JS, build better API's...?
At the moment I can't see a reason why you would want to use it for something, because I don't think I understand the concept of Backbone.js
The big advantage of rails is that you have one platform and one language that you use that will handle the server-code and can generate the client-code (using the views).
Undoubtedly this theoretical advantage quickly starts slipping once you want to improve your user-experience with javascript and jquery. So actually you still have to learn two languages.
But still: all your models, business-rules, ... is handled on the server-side in Ruby. This also means that the server always has to be reachable.
What a javacript/client MVC (like Backbone.js, Sproutcore, ...) can offer you is a more native application feel. A single web-page application, like e.g. Gmail.
Depending on your requirements there are some very valid use-cases for such a platform. E.g. in places or devices with low connectivity it could be very useful (with HTML5) to have a web-application that does not need to be "online" all the time. It could save data and edits to the local storage and sync back to the server/database when the device is back online.
But, there is a big disadvantage when developing client MVC applications in combination with Rails: you will have to do some double development (it is the same when you are using flex/silverlight). Your models will need to be defined both on the server and on the client. I can imagine that some improvements could be made, like on the client MVC you are actually using presenter-classes, which on the server-side could be stored in different models/tables. But still there will be duplication of logic, models, ...
So that's why I think that for most applications, at the moment, it is not wise to switch to some client MVC framework. It will be a lot more work.
But when you do need the look and feel of a real native application, or a one-page-web application, then a javascript client MVC framework is the way to go. And if you do need a client MVC framework, I would propose Sproutcore.
To simply ajaxify your current rails application (reduces load-time of every single page), take a look at pjax-rails.
(better late than never - hope this is useful to someone)
The description on backbonejs's website seems like a lot of words thrown together without much meaning. There is a big hype around it but what's all the fuss about?
The premise behind backbone is that modern day, single page web apps (think gmail) quickly become a very complex interaction between syncing dom elements, UI events and the backend. You could easily find yourself storing data within the dom elements, and then having to somehow extract the data again to update the database. If you don't structure your code very carefully, you'll quickly end up with spaghetti code full of complex bindings, or code without backbone.
Using backbone's models, collections and views gives you a well thought out structure to work within, allowing you to build large apps without being overwhelmed by their complexity. What's more, it ties in beautifully with a restful backend.
I am new to both Django and Rails. I am thinking of developing an Web 2.0 style application and is planning to expose Restful services, which my UI tier would call to make CRUD operations (Something similar to ADO.NET Data services)
I am yet to decide on the platforms and is looking for some advice on which one to side develop on?
I am currently thinking of Ruby on Rails or Django.
The benefit of using DJango / Python is that I can move to google AppEngine in future with some code changes, but on the down side I hear DJango is not RESTful.
I am also new to both Ruby and Python. So, what would be your advice on which platform to use?
Well if you want to couple the view and controller with REST then you are right that django is not RESTful, because with django you would have to (de)serialize django objects and manipulate that by yourself in the front end using your favourite javascript framework. Saying that, if your only concern is to send and receive data RESTfully without caring how to do it, then django should be sufficient for you since you've already got your heart for it.
Django is fine for REST applications. Rails claims to provide some functionality to that makes REST easier, but it is largely inaccurate - things like human-readable URIs don't really matter to REST. Rails auto-generates POST/GET/DELETE/PUT stuff for you, but it's just as easy to do in Django too - and it really doesn't have much to do with REST, either, it's just proper HTTP usage.
REST is a general type of architecture, it has very clear constraints, but there is no one, single way to do a REST application. This is a good discussion by the architect of REST, Roy Fielding, on some common misconceptions: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
I recommend Python and Django, but not for REST-related reasons. (Better documentation, a saner API with Django, less nasty monkey patching and black magic, less coupling, etc)
A RESTful interface is used for building distributed applications. Does your UI tier and services tier really need to be physically separated? Seems overkill to me.