Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Rapi::Blog talk - TPC 2017

340 views

Published on

Slides for talk on Rapi::Blog given at The Perl Conference 2017, June 20, Washington DC

Published in: Software
  • Be the first to comment

  • Be the first to like this

Rapi::Blog talk - TPC 2017

  1. 1. Henry Van Styn <vanstyn@cpan.org> The Perl Conference 2017 June 20, Washington, DC www.rapidapp.info rapi.io/blog irc.perl.org - #rapidapp Rapi::Blogmaximalist control, minimalist effort @vanstyn slides: rapi.io/tpc2017
  2. 2. About me • Henry Van Styn (@vanstyn) • Owner of IntelliTree Solutions, perl shop and consultancy • Author/maintainer of RapidApp • Catalyst and DBIx::Class contributor • Given talks/demos of RapidApp for the past several years at The Perl Conference
  3. 3. • This year I wanted to give a RapidApp demo of a bigger, real-world app that’s real-world useful • Married this with solving another of my long-time unmet needs: A real, modern perl blog platform…
  4. 4. Why another blog platform? • Many reasons, a better mousetrap… • RapidApp is already very well-suited to the problem domain Biggest reason: Fresh take on front-end APIs (i.e. “themes”)
  5. 5. The problem with “themes” • The word itself implies restrictiveness ‣ changing the appearance of something that is already defined • Inventing concepts of “pages” and “sections” and “blocks” and layouts and on and on and on that you have to adhere to • URL end-points are predetermined, rendered HTML assembled in domain- specific manner • Have to learn platform-specific APIs to even get to “Hello world” • Integrating and adapting custom HTML can be difficult and frustrating, especially when working with designers
  6. 6. Rapi::Blog’s approach: • Term chosen to give more emphasis than “theme” • Is an ordinary, native HTML website/structure first and handles its own business as much as possible • Lives at the root of the site like the HTML wants ‣ This is the main blocker elsewhere • Supports “opportunistic” templates ‣ But can still be static HTML, and just work • The backend exposes APIs the scaffold can use, however it wants “scaffolds”
  7. 7. Backend / Model Template API Basic Architecture: ‣ Public website structure ‣ Native HTML, CSS, JavaScript, Images, etc ‣ HTML can include template directives ‣ Database of ‘Posts’ ‣ Taxonomies ‣ Relationships ‣ Business Logic ‣ Permissions ‣ Expose Blog-specific template directives/methods Scaffold directory Advanced CRUD Interfaces RapidApp
  8. 8. Lets see it in action • Start with a running site, go through the public-facing functionality - browsing posts, pages, search, etc • Go through the password-protected features - creating/editing posts, comments, the new markdown editor, basic administration • Browse the scaffold config and the templates and how they work • Show how to create new sites with the rabl.pl create script - demo -
  9. 9. How it works • Rapi::Blog is a subclass of RapidApp::Builder • Plack/PSGI app with very simple options: my $app = Rapi::Blog->new({ site_path => $dir, scaffold_path => "$dir/scaffold" }); # Plack/PSGI app: $app->to_app
  10. 10. Options • site_path • directory where the site lives - used for data persistence • database files are created automatically for fresh sites • scaffold_path • the “document root” for the site • serves literal/real paths from “/” • defaults to ‘scaffold/’ inside the site_path directory
  11. 11. Scaffold • Ordinary directory served at the root of the site ✴ img/foo.png served as /img/foo.png, home.html served as /home.html, and so on • Merge/overlay with the Catalyst/RapidApp controller/module namespaces automagically • With no configuration it is a simple static website/folder • Any of the files can function as templates (TT) and call directives and accessors provided by the API • scaffold.yml config file tells the backend how to use it ✴ such as which template to use to display posts
  12. 12. The scaffold tells the backend what to do, not the other way around.
  13. 13. scaffold.yml static_paths : [ css/, js/, fonts/, img/ ] private_paths : [ private/, scaffold.yml ] default_ext : html landing_page : recent_posts not_found : private/404.html view_wrappers: - { path: post/, type: include, wrapper: private/post.html }
  14. 14. scaffold.yml static_paths : [ css/, js/, fonts/, img/ ] private_paths : [ private/, scaffold.yml ] default_ext : html landing_page : recent_posts not_found : private/404.html view_wrappers: - { path: post/, type: include, wrapper: private/post.html } * which paths are static-only (no template directives) - mainly for performance
  15. 15. scaffold.yml static_paths : [ css/, js/, fonts/, img/ ] private_paths : [ private/, scaffold.yml ] default_ext : html landing_page : recent_posts not_found : private/404.html view_wrappers: - { path: post/, type: include, wrapper: private/post.html } * paths which should not be served publicly (but can still be included from other templates)
  16. 16. scaffold.yml static_paths : [ css/, js/, fonts/, img/ ] private_paths : [ private/, scaffold.yml ] default_ext : html landing_page : recent_posts not_found : private/404.html view_wrappers: - { path: post/, type: include, wrapper: private/post.html } * default file extension (lets ‘/foo’ work the same as ‘/foo.html’)
  17. 17. scaffold.yml static_paths : [ css/, js/, fonts/, img/ ] private_paths : [ private/, scaffold.yml ] default_ext : html landing_page : recent_posts not_found : private/404.html view_wrappers: - { path: post/, type: include, wrapper: private/post.html } * page to serve for root (‘/’) request
  18. 18. scaffold.yml static_paths : [ css/, js/, fonts/, img/ ] private_paths : [ private/, scaffold.yml ] default_ext : html landing_page : recent_posts not_found : private/404.html view_wrappers: - { path: post/, type: include, wrapper: private/post.html } * page to serve for HTTP/404 Not Found
  19. 19. scaffold.yml static_paths : [ css/, js/, fonts/, img/ ] private_paths : [ private/, scaffold.yml ] default_ext : html landing_page : recent_posts not_found : private/404.html view_wrappers: - { path: post/, type: include, wrapper: private/post.html } * special URL dispatch template wrappers to expose “Posts” …
  20. 20. scaffold.yml view_wrappers: - { path: post/, type: include, wrapper: private/post.html }
  21. 21. scaffold.yml view_wrappers: - { path: post/, type: include, wrapper: private/post.html } Use this template (as a wrapper)
  22. 22. scaffold.yml view_wrappers: - { path: post/, type: include, wrapper: private/post.html } Use this template (as a wrapper) for requests starting with this
  23. 23. scaffold.yml view_wrappers: - { path: post/, type: include, wrapper: private/post.html } Use this template (as a wrapper) for requests starting with this e.g. this is how /post/some-name.md renders ‘some-name.md’ from the database
  24. 24. Showing the demo code • Browse the site dir • Browse the scaffold files • Show the scaffold.yml • Show the app.psgi
  25. 25. Creating a new site is easy rabl.pl create path/to/my-cool-blog
  26. 26. Easy setup with Docker docker pull rapi/psgi mkdir my-cool-blog docker create -it --name=my-cool-blog --hostname=my-cool-blog -p 5001:5000 -v $(pwd)/my-cool-blog:/opt/app rapi/psgi docker start my-cool-blog docker exec -it my-cool-blog bash # run in the shell of the Docker container: rabl.pl create /opt/app app-restart && exit
  27. 27. Planned TBD Features • Support multiple content formats ‣ Internals already support multiple formats and post-processors • Expand Post database model + expose easier access to customize • Add more prefabbed scaffolds with fancier features • Better user auth features ‣ login via 3rd-party, self-signup w/ captcha, password reset, etc • RSS feeds
  28. 28. Henry Van Styn <vanstyn@cpan.org> The Perl Conference 2017 June 20, Washington, DC Questions? @vanstyn www.rapidapp.info rapi.io/blog irc.perl.org - #rapidapp slides: rapi.io/tpc2017

×