rails_vs_sinatra.md

Intro to Rails

Sinatra vs Rails

• Sinatra is lightweight

  • web app back end not just consists of business logic (turning your idea into logical code)
  • it also include app security, initialization/setup of the server, configurations, folder structure, front end files management and more
  • the sinatra folder structure you get is pre-made by someone else, sinatra itself doesnt restrict you in file and folder structure
    • while it gives freedom, it also means there are a lot of stuff you’ll have to configure (mailers, backend workers, integrating them together with your business logic)
  • Production env and development env is different
    • OS different
    • more users using it, and many users use it at the same time, compared to you using it alone (unless load tested)
  • thus stuff you developed in your computer
  • Thus, Sinatra only gives you the bare basic you need to start a server that can accept internet request (parsing request and response), and it’ll eat up you/your team’s development time to launch an app by configuring database, background workers, etc.
  • • show bare basic sinatra *
  • However, it’s good for prototyping/pitching

• what Rails do that Sinatra doesn’t

  • Rails made by DHH and teams.
  • for different web applications, even though the business logic is different, the component that you’ll need for a web application is almost the same
    • template engine (erb, haml, slim)
    • most of the time, database integration (activerecord)
    • mailing
    • background workers
    • good way to manage front-end (css, js)
    • good routing
    • request and response (js, html)
    • etc.
    • sweet methods: http://guides.rubyonrails.org/active_support_core_extensions.html
  • authorization and authentication not included in the list, because there are many ways to do those
  • the aim of the framework is
    • to let the developer to focus mostly on turning the business logic into framework code, and build up a website, without having to worry about configurations
    • the tradeoff is Rails is pretty opinionated, which means you’ll have to learn how the framework wants you to write code (some practices and standards), aka convention
    • uses the MVC pattern for file organization
    • thus the term Convention over Configuration
  • because of this, Rails is pretty popular back then among the web dev community and got alot of support in terms of gem support/integration and the framework itself
    • Rails’ official documentation is good and detailed (may not be beginner friendly)
    • most gems found online are compatible with Rails (there are a few web framework for Ruby)
    • most tutorial found online are Rails-centric too
  • there are also people saying Rails is bloated with too many components that are not commonly used (and also the way they write the framework to infer stuff automatically). It’s good for small/medium scale, when large scale, might need to change.

• basically, they are just frameworks that allows you to do web development

• the most important part is to learn how the web works, not too focused on the framework itself, then you can transition to other framework easily

  • HTTP request response
  • sessions
  • routes (GET and POST, using :id matching in path)
  • templating engine
  • front-end components
  • library that allows you to query your DB
  • app testing
  • etc.

Parts of Rails that are different from Sinatra

• Routes (especially resources)
• Controller
  • methods name = view file name
  • redirect_to
  • before_action callback?
  • strong params
• form_for
• rails generators and commands
  • rails new with db postgresql (for heroku to work)
• asset files
  • image_tag
• link_to and form_for
• View
  • application.html.erb
  • partial
• Gemfile automatically require

web frameworks for Ruby: Rails, Sinatra, Volt, Grape, Padrino https://medium.com/hashdog-blog/top-10-ruby-frameworks-3cc1214caae7

• Try out rails official documentation