1 / 37

Techniques for Writing Web Applications in the API World

Learn how to write HTML5 and responsive web applications that are cloud-first, data-driven, mobile-friendly, and highly scalable. Explore different development approaches and find out which one suits your needs best.

rsmoot
Download Presentation

Techniques for Writing Web Applications in the API World

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. FEB 10th 2016 Techniques for writing Web applications in the API world Ljubomir Simin retro-hack.blogspot.com

  2. PLEASE RATE ME.

  3. Everything today has to be HTML5 and responsive ™ and cloud-first, data-driven, mobile friendly, cross-platform-compatible, service-oriented, lean, microservice-enabled, highly scalable, customer-centric with rich stateless API, high social traction and growth potential bigger picture outside of the box state of the art synergy paradigm shift jump the shark mission critical low hanging fruit influx

  4. But there’s barely enough time • Mandatory feature set • Estimates • Deadlines • Overtime / crunch

  5. It’s OK, we’re professionals • 7 out of 10 software developers think it’s OK to write mediocre software • 12 out of 15 QA engineers think software they test is crap • Most statistics on public presentations are made up • [this bullet intentionally left blank]

  6. It’s OK, we’re professionals • 7 out of 10 software developers think it’s OK to write mediocre software • 12 out of 15 QA engineers think software they test is crap • Most statistics on public presentations are made up

  7. It’s OK, we’re professionals (we really are) • We don’t write code without tests anymore • Writing quality software takes time • It has to be maintainable (by us or our successors) • We need to be nimble, provide competitive estimates - and keep them :( • Release early, release often

  8. Choosing a development approach • Respect the customer • Respect the management • Respect the team • Not necessarily in that order

  9. Client vs server • Server-side HTML • JSP, Thymeleaf, ASP.NET • Client-side HTML + data API • Angular.js, GWT, Vaadin, Backbone.js, Ember.js • Isomorphic applications • Meteor, Rendr, Derby

  10. Server-side HTML blic.rs http://zena.blic.rs HTML content blic.rs http://zena.blic.rs/dijeta.htm HTML content

  11. Server-side HTML • Data grouped in pages, documents • Every request results in rendering the whole page • Most of the business logic on the server

  12. Client-side rendering + API blic.rs http://zena.blic.rs JavaScript application blic.rs JS HTTP GET /api/articles/42 article data (JSON or XML)

  13. Client-side rendering + API • Data organized around domain model resources • Initial HTML is just a thin wrapper around JavaScript application • Application makes HTTP requests to API, gets data back and renders it • Domain logic scattered between API and client app

  14. Isomorphic application blic.rs http://zena.blic.rs HTML content + app blic.rs JS http://zena.blic.rs/dijeta.htm article data (JSON or XML)

  15. Isomorphic application • Speeds up initial page load by serving HTML, but loads JavaScript application asynchronously in the background, and behaves like a client-side app from there on • API can return data or markup • Usually same codebase reused on server and client (i.e. using node.js)

  16. Which approach is the best? ™ • Nothing is one-dimensional (except for things that are. Strings?) • Doing everything right ™ from the first go is not always an option • You should always decide what criteria matters to you

  17. Let’s compare approaches by: • Performance • Testability • Debugging tools • Development speed • Mobile application development • Search engine optimization

  18. Performance • Server side might be faster for low data amount, especially on mobile devices, while client-side rendering excels when there’s a lot of data. • Client-side application needs time to load and execute • Isomorphic approach has a great trade-off • Client-side uses less bandwidth, but more HTTP requests and connections

  19. Performance http://www.onebigfluke.com/2015/01/experimentally-verified-why-client-side.html

  20. Things to consider • You can improve performance by scaling backend vertically and horizontally but you can’t upgrade devices of your users • Browsers cache pages and files, but not requests • If performance is important consider isomorphic approach or just plain server with hand-crafted AJAX • Always measure! Fun fact - Twitter improved their load times 5x by rendering the HTML on the server compared to pure-client approach

  21. Testability • Unit tests on backend are easy • Integration tests on backend depend on backend structure • Functional tests are easiest on the API level • End-to-end tests slightly easier on server-side HTML (no waiting time and dynamic loading) but they’re fine on client side as well • JavaScript can be unit tested (finally!) • Whatever you want to test, there probably is a way. No excuses.

  22. Debugging • Debugging backend is mostly easy • Debugging HTTP requests is not hard either • Modern browsers have excellent debugging and profiling tools • Media query emulator • Viewport emulation • Debugging JavaScript is not difficult, even with frameworks like Angular.js • Isomorphic applications tend to be trickier to debug because of more code paths

  23. Development speed • Many older developers very familiar with server-side HTML • Client-side applications usually better decoupled - easier for mocking • Both approaches have strong contenders for easy prototyping, like SpringBoot + Thymeleaf, Grails + AngularJS • Client-side tends to have more overhead - packaging, deployment, duplicated models, logic, more tools, generally more decoupling and higher level of abstraction • Isomorphic approach is a relatively new player. Code reuse on server and client is a nice bonus.

  24. Mobile apps • (REST) API is naturally more suitable for writing an app • Even a server-side HTML applications can be packed into a serviceable app (using PhoneGap or WebView) as long as they are properly responsive, but single-page feels more native, snappier and performs better (JS can be bundled) • Responsive design always helps • Please, write great markup!

  25. Search engine optimization (SEO) • Crawlers need HTML • Server-side HTML approach have an advantage • Client-side apps can use tricks based on user agent • Share-ability of links (sharing on social networks, og-tags etc) • Isomorphic strikes again

  26. Example of server-side approach • SpringBoot for instant application skeleton • Spring MVC for MVC • Thymeleaf for templating • Spring security for authentication and authorization • JUnit with AssertJ for testing the backend • Cucumber for test readability • WireMock for mocking API dependencies • Protractor or Selenium for E2E tests • PhoneGap / WebView for basic mobile “app”

  27. What we got • A quickly developed application • Well tested and leaves confidence • Thymeleaf is great for both markup and templating • With some planning API can be added in parallel with MVC output • Spring security can be configured for both session and API-based approach providing easy upgrade path • Once API is there, functional tests are a no-brainer, and we can start writing proper mobile application

  28. Thymeleaf <htmlxmlns:th="http://www.thymeleaf.org"><head><linkth:src="@{/style/app.css}"rel="stylesheet"/></head><body><divth:if="${not #lists.isEmpty(users)}"><table><thead> … </thead><tbody><trth:each="user : ${users}"><tdth:text="${user.firstName}">John</td><tdth:text="${user.lastName}">Smith</td></tr></tbody></table></div></body></html>

  29. Example of a single-page application API: • SpringBoot • Spring security with token-based authentication • JUnit for unit tests, Cucumber for functional tests Client: • Angular.js app • Jasmine + Protractor for unit and end-to-end testing

  30. JavaScript behavioral testing with Jasmine describe('Hello world", function() { it('says world', function() { expect(helloWorld()).toContain('world'); });}); describe('Division test', function() { beforeEach(function() {this.addMatchers({ toBeDivisibleByTwo: function() {return (this.actual % 2) === 0; } }); }); it('is divisible by 2', function() { expect(gimmeANumber()).toBeDivisibleByTwo(); });});

  31. Some highlights • There’s no shame in starting with server-side HTML • API can be written at a later date, to both ease functional testing and enable writing more clients • Take whatever approach you feel the most comfortable • Consider going isomorphic

  32. Last thoughts • Whatever approach you choose write a great markup - it always pays off • Don’t mix tools and libraries with paradigms, know your stuff • Keep an eye on changing standards (CSS, HTML, better tools)

  33. Questions?

  34. PLEASE RATE ME.

  35. Useful resources • https://signalvnoise.com/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui • http://www.onebigfluke.com/2015/01/experimentally-verified-why-client-side.html • https://www.lullabot.com/articles/what-is-an-isomorphic-application • https://blog.twitter.com/2012/improving-performance-on-twittercom

  36. Thank you geekstone.org

More Related