• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Why you should consider a microframework for your next web project
 

Why you should consider a microframework for your next web project

on

  • 363 views

An explanation why you should consider to use a microframework over an MVC, depending on what you want.

An explanation why you should consider to use a microframework over an MVC, depending on what you want.

Statistics

Views

Total Views
363
Views on SlideShare
354
Embed Views
9

Actions

Likes
0
Downloads
1
Comments
0

2 Embeds 9

https://twitter.com 5
http://localhost 4

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Why you should consider a microframework for your next web project Why you should consider a microframework for your next web project Presentation Transcript

    • Why you should consider a microframework for your next web project by Joaquín Muñoz, age 24 and two thirds. @Chekosoft | github.com/Chekosoft
    • A good web framework is a good companion because it speeds up development (a lot) How? They implement and/or simplify most of the tedious tasks and boilerplate. ● Data manipulation ● Templating ● Security ● Session management ● {insert a tedious but necessary task to do}
    • The most popular MVC-based frameworks, like:
    • But MVCs have a little “problem” They are RIGID
    • But, before going like this: Because of my previous statement.
    • Why are they rigid? ● Strict adherence to a set of development patterns/philosophies/principles. ● If you want to replace one core component, additional work must be done. ● When a core component is replaced, some “magic” is gone with it. And replacement magic isn’t as good as the default one. ● Implementing your own magic/extensions/etc require from little modification to mashing your head on the table. (the previous statements may not apply to some frameworks)
    • But they’re rigid because they need to be All those cool features are built on top of a rigid, stable base. (Comfortable, too) So, it begs the question: Should I remove the cool things for customization?
    • Short answer: No. Long answer: OH GOD PLEASE NO! NO! NOOOOOOO!
    • “But I really want to do {x} on {y}” You have two ways: ● Roll Your Own ○ If it doesn’t remove core features: ■ Awesome! ○ If something else breaks in the process: ■ Welcome to Stack Overflow. ● Use a microframework
    • A microframework like only deals with a reduced set of tasks (mostly routing and session handling) Giving you freedom over the components/patterns/conventions you want/need to use.
    • Freedom is a keyword here
    • So, you can use anything you want to develop different aspects of your project ● ● ● ● ● NoSQL databases Custom templating engines ViewModel paradigm Custom user management or nothing at all with little or no additional work.
    • Think of a microframework as a nice foundation to stack the components of your future solution.
    • Another advantage of microframeworks If your project is small the code will be small. (most of the time) With an MVC framework, your project starts at almost medium size and then it grows from there (big projects won’t even notice).
    • An example Contoso wants to do a “Hello” public API. Which answers with “Hello!”. Let’s pretend this is a very interesting project.
    • If we use Rails, we should do something like: $ gem install rails $rails new hello-app $rails generate controller hello index $vim app/controllers/hello.rb (write the code) $emacs routes.rb (write the route file) $rails s #Success
    • It works... ...but all the additional components will only be using extra space. And it will require time to remove them (or you must remember to not include them in first place).
    • If we use Sinatra, this could be done as: $gem install sinatra $touch hello.rb $subl hello.rb require ‘sinatra’ get ‘/hello’ do ‘Hello!’ end $rails hello.rb == Sinatra has taken the stage … >> Listening on 0.0.0.0:4567
    • The same happens with Django and Flask With Django you need to create a project, then an application, then edit the controllers, add the created application to… (it keeps going on) With Flask, you need to do this after getting it using pip or easy_install (maybe not easy_install). from flask import Flask app = Flask(__name__) @app.route(‘/hello’) def hello(): return u’Hello!’ if__name__ == ‘__main__’: app.run()
    • With ASP.NET MVC, use Visual Studio. With Nancy, it’s like this: 1. 2. 3. Create a project with your favorite IDE. Get Nancy from NuGet Create a new file (C#) with the following. namespace Hello { public class HelloModule: Nancy.NancyModule { public HelloModule(){ Get[“/hello”] = _ => “Hello!” } } } Press F5, get bacon.
    • Thank you for your attention. And, if you want to use a microframework: Be Tidy (Or you’ll really regret it)