$30 off During Our Annual Pro Sale. View Details »

Going #frameworkless in the backend

Going #frameworkless in the backend

My presentation at Codemotion Milano 2018

Matteo Vaccari

November 29, 2018
Tweet

More Decks by Matteo Vaccari

Other Decks in Technology

Transcript

  1. THE ART OF #FRAMEWORKLESS IN THE BACKEND Matteo Vaccari @xpmatteo

  2. You have a choice, in your growth as a developer

  3. You may look for a simplified, maybe more pleasant way

    to deal with reality
  4. And look for a framework that will provide that simplified

    worldview for you. What is your growth path then?
  5. You can become a developer that knows his framework(s) very

    well. Your growth is in learning more frameworks and learn them better. You will have plenty to learn! And I don’t say this is necessarily bad. However…
  6. There is another way: you may want to deal with

    reality as it is. To go closer to the metal.
  7. To do this, you will need knowledge of a more

    fundamental nature. There is a world of things to learn! This kind of knowledge is more enduring, more versatile, more powerful.
  8. … and you may gain superpowers :-)

  9. Frameworks? Risk Functionality Performance Obsolescence Incompatibilities Developer Experience App startup

    time Test running time The bad The good Learning Standardisation Bad habits DB-Centric Quick project startup Extra work Upgrades Searching on Stackoverflow for answers Addiction Anything is good or bad in a particular context, for a particular set of goals.
  10. I prepared a small demo of an API that plays

    the game of hangman. I wrote three versions of it; the first uses Spring and JPA. The second replaces JPA with plain JDBC calls. The third one removes Spring and uses the Servlet API.
  11. Creating a new game All three versions respond in the

    same way. This is a sample of how to play.
  12. First guess: the letter “e”

  13. Second guess: the letter “t”

  14. Etc, etc…

  15. A small demo of how it feels to start a

    Spring/JPA service versus a plain Java one.
  16. Spring/JPA (Spring MVC) Controller Embedded Tomcat Spring MVC Servlet (Spring)

    Application Service (JPA) Repository Emtity Manager DB Our router Embedded Jetty Our Servlet Our Application Service Our Repository JDBC DB Domain Objects Domain Objects Domain Objects Domain Objects Domain Objects Domain Objects Domain Objects Domain Objects
  17. None
  18. None
  19. None
  20. None
  21. None
  22. Spring/JPA No Spring/No JPA (Spring MVC) Controller Embedded Tomcat Spring

    MVC Servlet (Spring) Application Service (JPA) Repository Emtity Manager DB Our router Embedded Jetty Our Servlet Our Application Service Our Repository JDBC DB Domain Objects Domain Objects Domain Objects Domain Objects Domain Objects Domain Objects Domain Objects Domain Objects
  23. HttpServletRequest HttpServletResponse A Java web application is (not exactly, but

    similar to) a function that transforms an HttpServletRequest into an HttpServletResponse.
  24. HttpServletRequest HttpServletResponse WebRequest WebResponse However, those servlet API objects have

    50+ methods and are very low level and hard to use. One key thing to make #frameworkless work well is to write simple code. Therefore, it’s good to transform the servlet API objects into something simpler and easier to use. These are custom made for each project, similar but never exactly the same thing.
  25. HttpServletRequest HttpServletResponse WebRequest WebResponse GameResponse x HttpStatus GuessRequest And this

    is still not enough; for any particular request, we probably want to transform the WebRequest into a specific request object that contains exactly what we need.
  26. Main

  27. The “Main Partition”

  28. The “Main Partition” The main and the servlet together are

    what Uncle Bob calls the “main partition”, that is, the place where objects are constructed. The main (of course) is executed once per process, while the servlet service method is executed once per request. It is a sort of “main” for the request.
  29. The Router

  30. The Router The router’s job is to decide what is

    the user trying to do, and dispatch to an appropriate service call. The code of the router is made much simpler by having some logic in the WebRequest and WebResponse.
  31. The Router, part II

  32. The Router, part IIFor a simple service, a chain of

    IFs is simple and effective. If the service grows, it will probably evolve towards a table lookup. Again, this object should be developed afresh for every project/service. There’s no need to create a reusable “custom framework” here.
  33. The Application Service

  34. The Application Service The application service job is (a) to

    invoke business logic on domain objects, and (b) to deal with non-functional effects such as persistence.
  35. The Domain Objects

  36. The Game Repository

  37. The Game Repository The GuessRequest contains data that are not

    used by the business logic, but are relevant for audit/security/debug purposes. This information is saved in a way that does not pollute the business logic (compare the GuessRequest, shown later, with the Guess domain object) The QueryRunner is from Apache Dblib. It’s possible to write your own; it’s no more than 10 lines of code.
  38. The Game Repository, part II

  39. The Game Repository, part II Reconstructing a Game involves replaying

    all the “guesses” of the player. This not exactly event sourcing, but it’s similar. I find that saving all the “events” involving an aggregate, with as little processing as possible at write time, makes persistence simpler, even when you don’t go full event- sourcing. Perhaps this way can be even better than full event-sourcing :-)
  40. The Web Request

  41. The Web Request The API of the WebRequest is at

    the same time simpler and higher level than the servlet API. The getOptionalParameter() and getMandatoryParameter() methods simplify the router and the service.
  42. The Guess Request

  43. Spring/JPA Spring/— —/— Server startup time ~6s ~3s 0.4s Time

    to run all tests 10s 5.5s 3.5s Time to run slowest test 7s 4-5s 1s # of tests 25 24 48 SLOC prod 360 424 643 SLOC test 358 357 745 jar size 30MB 17MB 6.3MB Judge for yourself.
  44. Frameworks? Risk Functionality Performance Obsolescence Incompatibilities Developer Experience App startup

    time Test running time The bad The good Learning Standardisation Bad habits DB-Centric Quick project startup Extra work Upgrades Searching on Stackoverflow for answers Addiction
  45. References https://github.com/xpmatteo/frameworkless-hangman https://github.com/frameworkless-movement/manifesto 45

  46. twitter.com/xpmatteo thoughtworks.com THANK YOU WE ARE HIRING! YES, IN ITALY!