I am just trying to get a better understanding of the full stack in development and all the different frameworks etc have gotten confusing in my head and I just want to try and wrap my head around everything. The main question is: What are the main differences between the front end, back end, database, and how do things like say Google Cloud Functions fit into all of this?
For instance, ReactJs is a frontend framework (technically library) that helps you build fast and responsive front ends using components. So with reactjs I could create a front-end to a web page with buttons and logic for moving around and showing data.
So in this case when and why would I add on a backend? For processing large amounts of data or running calculations is a good idea but how does this actually fit in? For instance Ruby on Rails uses the MVC framework so if I added Rails to a ReactJS project would the Reactjs part essentially just become the V (view) of the ruby on rails project? How does this compare to node.js and django? Why and when do I even use all of these?
Next, when adding databases into the mix when should I be using the front-end to use the database and when should I use the back end? For instance in a react app I could send and receive data from a firestore nosql database from the frontend but I could also make a ruby on rails app that creates migrations to alter the schema in lets say a postgresql database. So when and why should I be using each method?
Finally, one of my main questions is how do cloud functions fit into all of this? Do cloud functions just take away the "back-end" portion of the equation? I haven't used them but wouldn't you still have to write functions that take an input and spit back an output? Is the only difference with cloud functions that they are easier to maintain since you don't have to set up your own server?
What would common tasks and their differences be between a front-end and back-end developer?
The front-end talks to the backend. The backend then talks to the database, and relays info back to the frontend. The cloud is just a place to host your front/backend/database. Front-end developers build the User Interface (buttons, forms, screens, etc). Backend developers build the services that the front-end will push/pull data from, which it typically stores/retrieves from a database.
Related
We have our web application built completely on Ruby on Rails. The front end is tightly coupled with the backend. We are in a stage where we want to gradually start separating our frontend from the backend. We want to go ReactJS way with the UI part and we want to follow the waterfall model for the transition.
We have two options:
Use gem called react-rails, and build new components in React. Slowly start converting existing components into React components. Once we have all components converted into React components, take out every React component, separate complete frontend and host it somewhere else.
Host ReactJS somewhere else. Gradually start converting each component to React component, move it to new hosted place and remove them from Rails. The only catch is, React components will be located at a different location than where Rails is. While navigating within the app, it could give a feel of navigating to a different website.
Please share your experience and guide us on which way should we proceed. Our end goal is to have the complete front end in ReactJS and backend on Rails. They communicate via APIs, completely removing coupling between frontend and backend.
Thanks
Use #1 only if you plan on keeping rails in the server rendering mix (not recommended). If not then #2 is your best option to just start from scratch with a complete js solution. It doesn't have to feel like a different site if you create a decoupled react component library and a rendering pipeline to the existing rails app when it needs the new views. Then when you have converted all the view components you can wrap up the app logic and make the switch over entirely.
Another option is you don't even need to host the new react components seperately, the react components can go through a separate build cycle, then cached on the existing server and rendered as needed from rails.
I would actually NOT recommend going away from your Ruby centered system. You can use http://ruby-hyperloop.io to build your react.js components in Ruby. Hyperloop includes a Ruby DSL (HyperReact) for react, and HyperMesh which will give you complete access to your ActiveRecord models in your React components.
The huge advantages are you will deal with one language throughout, you do not need to build APIs just to access your data down at the client, and you can use the existing rails tool chain including test tools.
There is a huge library of React.js components which interoperate fine with HyperReact.
If for whatever reason you feel that it would be better to go the JS route then I would recommend react-rails. It works, is well supported, and handles prerendering (a very important concept.) You can easily integrate with NPM and webpack as well.
Disclaimer: We're a collection of scientists that are just now getting into python/ruby.
Project summary: We have analytics and usage data from social networking sites that we are using R and Highcharts (via lazy_high_chart gem) to present analytics to users through a website. The user can interact with this data by specifying which and when they want to investigate a social media segment. So the user defines the subject and the website responds with a slew of metrics.
Problem: So far we have been using straight ruby to pull social networking data (one class), send it to the analytics engine (another class), and present it in plotted glory (final class). However, this is all been proof of principle and console driven so it seems inefficient to push it to a site from this start. Should we have started from the ground up with a rails framework and just built the site with all of these analytic engines built into the site? Or...is it better to have this backend pipeline written in ruby that only interfaces with a rails framework trough yet another object?
A suggestion or pointer to a general document that hints on how to integrate backend data crunching with frontend rails would be great.
Your question is basically how to architecture the system, and this is somewhat hard answer since it usually depends on a lot of things: system requirements, application landscape, project planning, skills, etc.
But just looking at the two alternatives you mentioned, I think there's nothing wrong with creating a fresh Rails application, copying your prototype modules into the lib/ directory and connecting things the standard way. You can use rake tasks to keep the console interface you already have. In the end, your setup looks quite similar to a standard web application. (Usually you have a database doing the "data crunching", in your case it is the R engine.)
I don't know any specific documentation about integration Rails with R, but some research about general system integration with Rails should give you a good starting point. (However, this would only be needed if you really want to build two independent systems.)
We are planning to make a "large" website for I'd say 5000 up to many more users. We think of putting in lots of real time functionality, where data changes instantly propagate to all connected clients. New frameworks like Meteor and DerbyJS look really promising for this kind of stuff.
Now, I wonder if it is possible to do typical backend stuff like sending (bulk) emails, cleaning up the database, generating pdfs, etc. with those new frameworks. And in a way that is productive and doesn't suck. I also wonder how difficult it is to create complex forms with them. I got used to the convenient Rails view helpers and Ruby gems to handle those kind of things.
Meteor and DerbyJS are both quite new, so I do expect lots of functionality will be added in the near future. However, I also wonder if it might be a good idea to combine those frameworks with a "traditional" Rails app, that serves up certain complex pages which do not need realtime updates. And/or with a Rails or Sinatra app that provides an API to do the heavy backend processing. Those Rails apps could then access the same databases then the Meteor/DerbyJS app. Anyone thinks this is a good idea? Or rather not? Why?
It would be nice if anyone with sufficient experience with those new "single page app realtime" frameworks could comment on this. Where are they heading towards? Will they be able to handle "complete" web apps with authentication and backend processing? Will it be as productive/convenient to program with them as with Rails? Well, I guess no one can know that for sure yet ;-) Well, any thoughts, guesses and ideas are welcome!
For things like sending bulk emails and generating PDFs, Derby let's you simply use normal Node.js modules. npm now has over 10,000 packages, so there are packages for most things you might want to do on the server. Derby doesn't control your server, and it works on top of any normal Express server. You should probably stick with Node.js code as much as possible and not use Rails along with Derby. That is not to say that you can't send messages to a separate Rails app, but since you already have to have a Node.js app running to host Derby, you might as well use it for stuff like this.
To communicate with such server-side code, you can use Derby's model events. We are still exploring how this kind of code works and we don't have a lot of examples, but it is something that we will have a clear story around. We are building an app ourselves that communicates with an email server, so we should have some real experience with this pretty soon.
You can also just use a normal AJAX request or send a message over Socket.IO manually if you don't want to use the Derby model to do this kind of communication. You are free to make your own server-side only routes with Express along with your Derby app routes. We think it is nice to have this kind of flexibility in case there are any use cases that we didn't properly anticipate with the framework.
As far as creating forms goes, Derby has a very powerful templating system, and I am working on making it a lot better still. We are working on a new UI components feature that will make it possible to build libraries of self-contained UI widgets that can simply be dropped into a Derby app while still playing nicely with automatic view-model bindings and data syncing. Once this feature is completed, I think form component libraries will be written rather quickly.
We do expect to include all of the features needed for a normal app, much like Rails does. It won't look like Rails or work like Rails, but it will be similarly feature complete eventually.
For backend tasks (such as sending emails, cleaning up the database, generating pdfs) it's better to use resque or sidekiq
Now, I wonder if it is possible to do typical backend stuff like
sending (bulk) emails, cleaning up the database, generating pdfs, etc.
with those new frameworks. And in a way that is productive and doesn't
suck. I also wonder how difficult it is to create complex forms with
them. I got used to the convenient Rails view helpers and Ruby gems to
handle those kind of things.
Also, my question is not only about background jobs, but also about stuff one can might do during a request, like generating a pdf, or simply rendering complex views with rails helpers or code from gems. –
You're mixing metaphors here - a single page app is just a site where the content is loaded without doing a full page reload, be that a front end in pure js or you could use normal html and pjax.
The kind of things you are describing would be done in a background task regardless of the fornt-end framework you used. But +1 for sidekiq if you're using ruby.
As for notifying all the other users of things that have changed, you can look into using http://pusher.com or http://pubnub.com if you don't want to maintain a websocket server.
I'm going to be collaborating with a Python developer on a web
application. I'm going to be building a part of it in Ruby and he is
going to build another part of it using Django. I don't know much about
Django.
My plan for integrating the two parts is to simply map a certain URL
path prefix (say, any request that begins with /services) to the Python
code, while leaving Rails to process other requests.
The Python and Ruby parts of the app will share and make updates to the
same MySQL datastore.
My questions:
What do people think generally of this sort of integration strategy?
Is there a better alternative (short of writing it all in one language)?
What's the best way to share sensitive session data (i.e. a logged in
user's id) across the two parts of the app?
As I see it you can't use Django's auth, you can't use Django's ORM, you can't use Django's admin, you can't use Django's sessions - all you are left with is URL mapping to views and the template system. I'd not use Django, but a simpler Python framework. Time your Python programmer expanded his world...
One possible way that should be pretty clean is to decide which one of the apps is the "main" one and have the other one communicate with it over a well-defined API, rather than directly interacting with the underlying database.
If you're doing it right, you're already building your Rails application with a RESTful API. The Django app could act as a REST client to it.
I'm sure it could work the other way around too (with the rest-client gem, for instance).
That way, things like validations and other core business logic are enforced in one place, rather than two.
A project, product, whatever you call it, needs a leader.
This is the first proof that you don't have one. Someone should decide either you're doing ruby or python. I prefer ruby myself, but I understand those who prefer python.
I think starting a product asking yourself those kind of questions is a BAD start.
If your colleague only knows prototype, and you only know JQuery, are you going to mix the technologies too? Same for DB? And for testing frameworks?
This is a never ending arguing subject. One should decide, IMHO, if you want so;ething good to happen. I work with a lot of teams, as a consultant, Agile teams, very mature teams for some of them, and that's the kind of stuff they avoid at all cost.
Except if one of you is going to work on some specific part of the project, which REALLY needs one or other of the technologies, but still think the other one is best for the rest of the application.
I think, for example, at a batch computing. You have ALL your web app in ror or django, and you have a script, called by CRON or whatever, computing huge amounts of data outside the web app, filling a DB or whatever.
My2Cts.
I am developing my first Rails app, a web replacement to a paper form system. Some way through development I discover my client wants to be able to add ad hoc new forms to the live system.
I have considered using wufoo/ google forms/ or survey monkey, but I don't think they are going to fit the bill, due to integration requirements.
What I basically want is to enable one or two super-users to create forms, which will then be available to other users in the system. When the forms are completed the output should be made available to my system. The data is to be manually collated for analysis, so even CSV is fine - there is no need for complex modelling.
I have been struggling to find any paths to a solution - I really don't want to build a form builder myself! So if anybody can point me in the right direction it would be most appreciated!
Cheers!
The liquid template is a good choice for custom building web pages. The easier approach is creating pure HTML pages with form to your system, if your customer allows to.
For the data storage, you'd better try nosql database, such as the mongodb and mongo gem as the ruby adapter, so you can save any data structure without managing the tables and columns. By the way, you have to learn some ruby meta-programming skills to process the dynamic data from the client.