Summarized using AI

Hanami 2.0 and You

Christine Seeman • March 28, 2023 • online • Talk

In the video titled "Hanami 2.0 and You," Christine Seeman discusses the features and functionality of the Hanami 2.0 web framework, emphasizing its design for Ruby developers. The presentation begins with a metaphorical introduction centered around springtime, linking it to Hanami, which means 'cherry blossom viewing' in Japanese. Seeman highlights the evolution of Hanami to a modern web framework, focusing on key aspects that enhance maintainability, testability, and scalability of web applications.

Key points discussed include:

  • Hanami's Background: Seeman introduces Hanami as a web framework written in Ruby, built with an emphasis on testability and maintainability. The latest version, Hanami 2.0, is a complete rewrite benefiting from the dry-rb ecosystem.
  • Folder Structure and Accessibility: Hanami features an intuitive folder structure that resembles existing frameworks like Rails, which makes it accessible for Ruby engineers.
  • Maintainability: The framework utilizes Hanami containers to load dependencies efficiently, resulting in faster boot times and better performance compared to traditional Rails applications. Seeman emphasizes this efficiency as key in scaling applications.
  • Testability: Hanami offers a dependency injection helper called "depths," allowing clearer management and testing of dependencies, thus improving the overall testability of applications.
  • Scalability: Hanami implements a concept called 'slices,' which enables developers to create mini applications within a main application, promoting clear boundaries and better organization.
  • Real-World Applications: Seeman shares insights from her work, reflecting on the use of Hanami for API development, particularly in her production application with considerations for speed and efficiency.
  • CLI Features: The dry CLI integration in Hanami allows for custom command-line tool development, which enhances productivity and simplifies task automation.

The session also briefly touches on some limitations of Hanami, particularly regarding its persistence layer using ROM, which presents a learning curve for those accustomed to Active Record in Rails. Overall, Christine's presentation effectively conveys how Hanami 2.0 is designed to address common pain points in web development while promoting a cleaner, more modular architecture.

Key takeaways from the video include:
- Hanami 2.0 is a significant advancement in Ruby web frameworks focusing on modularity and efficiency.
- The concepts of maintainability, testability, and scalability are central to Hanami's design.
- Hanami can be integrated into existing projects smoothly, allowing developers to enhance their applications incrementally.

Hanami 2.0 and You
Christine Seeman • March 28, 2023 • online • Talk

Let's chat about the new release of Hanami 2.0 Web Framework and what you can use it for. Let's learn how you can start with it, and some examples from an application that is already making use of Hanami in production.

Christine Seeman is a lifetime learner from Omaha, NE, where she likes to read too much and eats food that probably took too long to prepare. Professionally she's solving problems on the Identity team at WP Engine by writing secure, easy-to-read software that powers authorization and authentication.

https://www.wnb-rb.dev/meetups/2023/03/28

WNB.rb Meetup March 2023

00:00:00.179 okay so uh I'm from Omaha Nebraska uh
00:00:05.100 and we don't quite have spring yet so I
00:00:08.580 wanted with my presentation to bring
00:00:10.800 spring uh so I uh brought all the spring
00:00:14.160 colors in and um if you haven't heard
00:00:17.220 what Hanami is uh Hanami is the Japanese
00:00:20.939 uh phrase for describing cherry blossom
00:00:24.539 viewing and so I thought even though it
00:00:27.779 is end of March uh let's bring some uh
00:00:30.420 spring time for us uh and let's talk
00:00:33.899 about Hanami
00:00:39.120 so last month uh with uh Jenny she
00:00:42.920 hybrada's functional programming for Fun
00:00:45.480 and Profit let's kind of continue that
00:00:48.600 dry RB journey in chat about Hanami so
00:00:52.440 these faces and people may be familiar
00:00:54.840 to us uh so Tim Reilly Peter slinka and
00:00:58.980 Luca Guida are all dry RB core members
00:01:02.579 but news they also are Hanami Corey
00:01:06.659 members and so this is important to
00:01:09.119 realize when we start learning more
00:01:11.280 about kanami is that it is uh very tight
00:01:14.939 and very uh
00:01:16.799 like what is actually brought in is a
00:01:20.040 lot of relies on uh things from your IRB
00:01:22.979 and then the opposite sometimes when uh
00:01:26.100 these contributors are working on stuff
00:01:28.320 and Hanami it it may end up into a dry
00:01:31.680 RB and so you'll see a lot of this
00:01:34.200 ecosystem kind of goes back and forth
00:01:36.299 but let's dive in on what exactly is
00:01:39.960 Hanami and I did not time myself so uh
00:01:44.880 hopefully it will be okay on time but if
00:01:47.880 I do go over I apologize
00:01:50.280 but Hanami is a modern web framework and
00:01:54.899 it's you know for Ruby so that's why
00:01:56.880 we're kind of talking about it here at
00:01:58.979 our Ruby Meetup and so with that kind of
00:02:01.680 web framework it's to support the
00:02:03.540 development of our different web
00:02:05.040 applications we may have web services or
00:02:07.799 other web resources maybe you have some
00:02:10.340 B2B your business business type services
00:02:13.200 or maybe you have web apis and this is
00:02:16.739 what those are it is aimed at
00:02:21.120 and what the developers and these core
00:02:24.840 contributors wanted out of Hanami
00:02:27.000 especially Hanami 2.0 is that they
00:02:29.819 wanted to focus on how to make something
00:02:31.739 maintainable how to make it testable and
00:02:35.040 how to scale it because we all are
00:02:37.440 working on applications but where our
00:02:39.840 applications are right now is never
00:02:42.420 where they're going to be going in the
00:02:44.099 future and so to focus even on the
00:02:46.920 beginning on how to keep that scale
00:02:51.900 and so with that and thinking about how
00:02:55.260 we're bringing in the dry RB it's about
00:02:57.000 how to create those uh applications that
00:03:00.480 they're really a system of those
00:03:02.459 components working together with clear
00:03:04.760 dependencies and as Ruby as our Dynamic
00:03:08.099 language we don't always have the most
00:03:10.319 Clarity on where those dependencies are
00:03:12.959 coming from
00:03:15.840 so is anybody here right now working on
00:03:19.019 a big rails app you can do your virtual
00:03:21.420 high you can do okay so you understand
00:03:26.300 that rails apps get big quickly that
00:03:30.300 it's just it's easy to pile on feature
00:03:33.000 it's easy to pile on the things you're
00:03:34.739 like hey you know I started out as a web
00:03:37.739 application but hey you know I want to
00:03:40.680 people to pay for stuff so I'm just
00:03:42.239 going to add a billing on to that no hey
00:03:44.340 we have customers how about we just you
00:03:46.379 know throw on you know like some a web
00:03:48.540 form in there too and then like your app
00:03:51.060 gets bloated very quickly and so that's
00:03:54.659 one thing that a lot the maintainers of
00:03:56.760 Hanami were trying to help prevent is
00:03:58.860 how can you make it you know that system
00:04:00.959 of the components
00:04:02.819 but it's can scale because big wet rails
00:04:07.019 apps aren't necessarily in the big the
00:04:09.599 best things that scale
00:04:12.480 and so let's dive in and see what it
00:04:15.000 looks like
00:04:16.260 um
00:04:19.079 but just one thing to consider first if
00:04:22.199 you have been familiar with Hanami maybe
00:04:24.540 you checked it out in one of its uh
00:04:26.400 beginning releases uh like a Nami One
00:04:29.280 Zero type release
00:04:31.740 and with Hanami 2o it was a pretty much
00:04:35.040 a rewrite from the dry RB foundation and
00:04:38.759 so
00:04:39.620 a lot of the things that were created in
00:04:42.479 Hanami one were kind of used but Hanami
00:04:46.139 2 is a completely different beast and so
00:04:48.479 if you look at it at one you really do
00:04:50.759 need to reconsider it with the 2-0
00:04:53.400 release
00:04:54.960 and so this is kind of like a basic uh
00:04:57.840 folder structure we just create
00:04:59.940 ourselves a brand new Hanami app with a
00:05:02.699 generator that they have and so a lot of
00:05:05.639 these files in that folder structure is
00:05:07.979 going to be familiar we get it's a rack
00:05:09.660 based uh web framework going on there we
00:05:12.060 got uh gem files and we got a lot of the
00:05:14.460 folders and structures we already kind
00:05:16.740 of expect if you have been familiar with
00:05:19.139 rails or other Frameworks and so it's
00:05:22.139 very approachable in that you know hey
00:05:25.139 what should be underneath my app
00:05:26.699 directory probably where most of my
00:05:28.680 application codes at what if I don't
00:05:31.380 know if think it belongs to another app
00:05:33.000 maybe I'll just stick underneath lib
00:05:35.039 that's the supporting code structure so
00:05:37.199 it's very intuitive on where the stuff
00:05:39.300 probably is at and if you need to open
00:05:41.940 up a Hanami app you kind of know as of
00:05:44.400 reels or a ruby engineer where should I
00:05:47.160 go to
00:05:49.199 but
00:05:50.820 let's dig in on how it actually does
00:05:53.460 those things that it said it was kind of
00:05:55.560 going for so how does it actually
00:05:58.560 help with maintainability
00:06:01.380 well one way is through the use of like
00:06:04.139 it's Hanami containers which is built on
00:06:06.360 dry RP container
00:06:08.220 it uses site work for its uh loading and
00:06:11.880 so this is important because this is
00:06:13.259 something that that even rails right now
00:06:15.000 is moving to so it's efficient and it's
00:06:17.699 a thread save code loader
00:06:20.100 um before it used to be classic for
00:06:22.080 rails up and you had to switch over to
00:06:24.720 site work I think it's version six and
00:06:27.419 so now this is actually the top of the
00:06:30.479 line code loader with Hanami so stuff
00:06:33.120 loads fast
00:06:35.100 and it helps you do that with not much
00:06:38.160 effort it's the default yes it
00:06:41.100 definitely could be me misspelling stuff
00:06:43.380 so yes thanks
00:06:45.180 and what it helps with is it with that
00:06:48.960 efficient thread safe code loader it
00:06:51.120 does it fast and it loads in your
00:06:53.160 dependencies which helps with your boot
00:06:55.500 climbs but rails May kind of eager load
00:06:59.580 every single constant ever it kind of
00:07:01.979 lazy loads those so once again helping
00:07:04.620 us speed up that boot time
00:07:06.600 and then it has stuff in the Nami
00:07:09.660 container that is special in itself so
00:07:11.880 you have your app core which you can
00:07:13.860 just use that to return anything as a
00:07:16.259 component so you boot up a console I can
00:07:19.080 access any of my actual actions think
00:07:22.800 about them as my API endpoints
00:07:25.860 and the console which as developers you
00:07:30.120 will probably live sometimes in a rails
00:07:32.520 console is fast to boot up uh I have a
00:07:36.360 production app and then I have this
00:07:38.160 brand new example app I had done my boot
00:07:40.800 time for my console was the same it
00:07:44.160 didn't feel anything noticeably
00:07:45.780 different and that helps with the
00:07:47.460 scaling and the combination of how it's
00:07:49.380 doing that code autoloading
00:07:53.639 okay
00:07:58.080 but what about testability
00:08:03.120 what Hanami has is a thing called depths
00:08:05.699 which yes it takes a little bit to get
00:08:07.500 used to I thought it was kind of abrupt
00:08:09.120 when we do better with our naming but it
00:08:12.240 really is a friendly dependency
00:08:13.620 injection Helper and it this is one of
00:08:16.800 the core things that I really love after
00:08:19.620 using Hanami for months
00:08:21.960 so it really helps to remove rigid
00:08:24.780 dependencies because it's easy to use
00:08:26.400 it's intuitive and it's right there
00:08:29.220 and so when dependency injection is easy
00:08:32.219 to do you are going to reach for a
00:08:34.560 dependency injection and so it's just a
00:08:37.500 mix-in that you add in anytime you need
00:08:39.539 to do this and I got a code example so
00:08:41.399 don't worry about that uh to just allow
00:08:44.159 you to use any component as a dependency
00:08:46.560 and then when you have that depth that
00:08:48.720 helps with being able to know where all
00:08:51.720 your dependencies at
00:08:56.040 and when you are using dependencies and
00:08:59.279 you're using your dependency injection
00:09:00.720 that means when you test you can
00:09:02.940 actually depends the interact your mocks
00:09:05.700 anything you're using in your testing so
00:09:07.920 it makes your components easier to test
00:09:11.100 so this is just a quick example from on
00:09:13.920 the Hanami site that was kind of showing
00:09:17.580 hey I need to send a welcome email in my
00:09:20.940 app
00:09:21.839 but I have to directly tie my client I
00:09:25.860 have to directly tie the thing at
00:09:27.300 rendering and then
00:09:29.339 when I'm actually delivering that email
00:09:31.019 you can see it's hard coded that I have
00:09:33.600 my renderer and I have what I'm
00:09:36.120 rendering
00:09:37.620 then when we kind of reach instead to
00:09:41.100 using depths
00:09:42.480 what we have is the depth mix and
00:09:45.839 include depths I just uh give it the
00:09:49.260 email client and I use the give it the
00:09:51.720 what I want to render and then here
00:09:54.600 I can see that I just do email
00:09:57.320 client.deliver that depth mixin means
00:10:00.600 you don't have extra atom readers you
00:10:02.640 don't have other boilerplate like an
00:10:04.500 initializer so it really helps you
00:10:06.540 compose those together so much simpler
00:10:09.240 and then look at your readability of
00:10:11.339 your code
00:10:16.380 but we all know that sometimes we don't
00:10:19.200 have time in our schedule to do
00:10:21.480 Greenfield development sometimes we're
00:10:23.760 not at the perfect point in a project
00:10:25.920 where you come in when everything's
00:10:27.420 getting spun up
00:10:28.920 and so what you can do with Hanami is
00:10:32.700 you can do a little part of it like
00:10:35.640 kind of the best part of it which is
00:10:37.980 actually
00:10:39.360 the Hanami API HW framework so this
00:10:43.800 framework is fast
00:10:46.140 so if you need to like add in uh some
00:10:49.620 HTTP apis which everything is apis
00:10:53.339 nowadays it feels like it is a extremely
00:10:56.100 lightweight Ruby way of adding it into
00:10:58.860 your already existing code base
00:11:01.019 and it's a ideal mini framework so it's
00:11:04.560 a good place to start introducing some
00:11:07.220 Nami into an existing app uh the
00:11:11.519 maintainers themselves have been doing a
00:11:13.560 lot of different kind of um
00:11:16.800 kind of look at how they can keep this
00:11:19.740 fast and lightweight and this is kind of
00:11:22.680 from sorry this is kind of from when
00:11:26.220 they were doing that on the HTTP
00:11:29.160 framework there
00:11:34.579 back and you can see
00:11:37.560 at the bottom the big numbers which are
00:11:40.680 the bad badder ones here uh so you want
00:11:44.160 the golf score is the uh Hanami is right
00:11:47.519 at the top on how quick it was able to
00:11:49.980 get through on those requests or how
00:11:52.740 like you know when you have an app
00:11:55.500 you're gonna start having lots of routes
00:11:57.600 so sometimes it's not about just doing
00:11:59.579 stuff fast it's about doing stuff
00:12:01.560 through how many different things you
00:12:03.779 have and so you can even though when you
00:12:05.579 have lots and lots of routes going on in
00:12:07.620 your application routes kind of equal
00:12:10.260 you know like apis uh then you can still
00:12:13.980 get through that quickly
00:12:18.600 but with all this uh you might want to
00:12:21.660 get your hands dirty with some of the
00:12:23.339 code there's a getting started guide on
00:12:26.100 Hanami or there's a a new app that I
00:12:29.880 just uh put out and I'll get the GitHub
00:12:32.459 info for people is a picnic because if
00:12:35.220 we are going to go view some cherry
00:12:36.540 blossoms I think we need a picnic
00:12:38.579 involved and so uh we can check that out
00:12:43.200 a little bit just to see what this is
00:12:45.720 I'm sorry if this is kind of small text
00:12:48.120 but we'll get you know the uh uh the
00:12:51.120 GitHub out for people to look at but
00:12:53.399 what this uh kind of wanted to show is
00:12:56.700 yes like we'll still have like a gem
00:12:58.980 file in a lot of the the other stuff you
00:13:01.560 just need for wake it bakes systems but
00:13:04.920 it also will kind of show up
00:13:07.320 the dependency injection
00:13:09.240 so we'll see that depths mix in here but
00:13:12.000 it also shows how easy it is to spin up
00:13:15.420 a brand new API
00:13:17.399 tie in your persistence layer so this is
00:13:19.980 through ROM and if we have more
00:13:21.600 questions about persistence in the
00:13:23.100 database later I would be happy to
00:13:24.540 answer that
00:13:25.920 um and then just how quick it is to just
00:13:28.560 uh set that whole like kind of Stack the
00:13:32.399 from the front of your API all the way
00:13:35.220 down to your DB the startup is a pretty
00:13:37.800 darn quick
00:13:41.700 oh
00:13:46.920 now the other thing they said they were
00:13:48.959 pretty good at was scaling and this is
00:13:51.240 one of those that you can't really tell
00:13:53.519 how good it is until you start using it
00:13:55.500 for a while but um
00:13:57.959 with it they have added a component
00:14:01.019 that's called slices so if you're
00:14:03.420 familiar with rails and you're familiar
00:14:05.220 with big rails apps you know engines and
00:14:09.300 engines have their benefits with trying
00:14:12.000 to break down a monolith but they also
00:14:14.279 have their drawbacks they're usually
00:14:16.079 fairly clunky they usually aren't easy
00:14:18.180 to implement after the fact you can kind
00:14:20.880 of tear the code into there then the
00:14:23.339 nice thing with Hanami slices is they
00:14:25.800 are a
00:14:26.880 built-in concern that has generators
00:14:29.760 behind it but also how they draw the
00:14:32.700 boundaries is very clear because it's
00:14:35.639 building on that dry container it's
00:14:37.620 building on all that kind of dry
00:14:39.540 components they are very composable
00:14:42.060 together
00:14:45.660 so yeah it was just this built-in
00:14:47.279 facility for organizing your code so
00:14:49.860 think about it like a folder structure
00:14:51.600 it allows you to kind of draw everything
00:14:54.019 down the folder hierarchy just kind of
00:14:57.959 one deeper but do it in a way that they
00:15:00.180 compose together nicely and when you
00:15:03.120 actually ship out your code you can have
00:15:04.800 separate containers for each slice so
00:15:07.740 you may have in your GitHub your full-on
00:15:10.620 Hanami app but you may have slices which
00:15:13.500 then you can use in your CDI CD Pipeline
00:15:15.899 and have those individual containers
00:15:19.199 which if anybody has been doing some
00:15:20.940 yaml and CI CD lately uh I can tell you
00:15:23.760 it's nice when they compose together and
00:15:26.339 you can they just work
00:15:31.680 oppa I think I went a little fast but
00:15:34.380 this this is kind of just showing off
00:15:36.240 once again we're kind of looking at the
00:15:38.100 hierarchy and
00:15:39.959 um this is actually in my uh customer
00:15:42.180 item knee access management app
00:15:45.180 um we have a couple different slices we
00:15:47.459 kind of started off doing
00:15:49.199 uh stuff for a customer identity which
00:15:52.380 kind of evolved around single sign-on
00:15:54.540 but then we got oauth thrown at us and
00:15:57.420 like that may not seem like the same
00:15:59.040 thing but customer identity is about who
00:16:02.339 is the user and then with authorization
00:16:04.380 it's who can access the user and then
00:16:07.019 authentication is are you allowed to
00:16:08.940 access the user and so we can also have
00:16:12.540 some skim going on there which is
00:16:14.279 another way of doing user management
00:16:18.000 there's a lot of acronyms I'm sorry we
00:16:20.339 try our best with me sometimes you do
00:16:22.440 you just have only so many things you
00:16:24.300 can name it
00:16:26.779 and then so you can see on the left is
00:16:30.060 the higher view of your slices and it
00:16:32.639 has a full application and then you when
00:16:35.160 you dive in on your slices you can kind
00:16:37.079 of see there are many apps themselves
00:16:38.519 they may have the actions which are the
00:16:41.160 endpoints they may have uh their own
00:16:43.860 database layer their own database access
00:16:46.620 as well as their own like different
00:16:48.899 grouping and um clients that they'll
00:16:52.980 have to consume and uh just things that
00:16:56.100 are imported to them hey Rose what's up
00:17:00.300 um I was just curious so could I like
00:17:03.240 visualize a slice like an individual
00:17:06.660 micro service but without that Network
00:17:08.819 boundary between the services or is that
00:17:11.640 taking it too extreme that's a little
00:17:14.040 bit too extreme so it's
00:17:16.559 um think about it as how they usually
00:17:19.679 describe it is like a mini application
00:17:21.540 in a bigger application so we keep some
00:17:24.059 like shared a code so maybe we have a
00:17:26.699 API or Gateway provider that's used over
00:17:29.580 multiple slices so you may have that at
00:17:31.919 your base app layer and then underneath
00:17:33.900 your slices you can have them themselves
00:17:37.100 using the base layer code but you may
00:17:41.160 have like your database persistent layer
00:17:43.380 could be completely different with a
00:17:45.660 different logical databases using the
00:17:48.059 same actual post Quest regress database
00:17:51.059 and that
00:17:52.380 okay really cool thank you yeah hey Kaja
00:17:56.100 can I help you
00:17:57.960 yeah I was wondering if you would also
00:17:59.940 then deploy them together or you can can
00:18:03.000 you deploy them independently
00:18:07.679 we deploy them out independently of each
00:18:10.620 other uh since uh what they kind of are
00:18:13.620 are separate microservices we keep them
00:18:16.440 in completely separate uh deploys
00:18:19.200 and so like we have them out out in the
00:18:21.480 cloud they're in the kubernetes with all
00:18:23.880 the k8s uh going on there and so they're
00:18:26.580 actually a separate different containers
00:18:31.740 I love questions thank you so much that
00:18:34.440 means you guys are listening to me
00:18:37.620 so I'm going to talk about the CLI uh
00:18:40.559 quick for a little bit just because it
00:18:42.419 was one of my first entrances into like
00:18:45.059 Hanami dry RB that I was really just uh
00:18:48.539 amazed at everything I could do with it
00:18:50.460 which this is technically more dry RB
00:18:53.100 over Hanami but we've already known that
00:18:55.260 that line gets a little murky
00:18:57.539 so with the dry CLI this is your way of
00:19:01.740 creating CLI commands for yourself I
00:19:05.280 love them before like having them as
00:19:07.260 like individual developer tools if you
00:19:09.600 think of that as like you can compose
00:19:11.520 your own CLI tooling that uses your code
00:19:14.640 on the back end so think about hey I'm a
00:19:17.340 developer and I manually have to call
00:19:21.480 off to an API like I need to do a IDP uh
00:19:26.220 identity provider and create a saml uh
00:19:30.260 saml instance I'm so sorry if I do so
00:19:32.820 many identity uh based kind of examples
00:19:36.179 that's my land right now uh and so if
00:19:39.000 you want to do that and you want to
00:19:40.919 maybe use an API client you already have
00:19:43.140 coded up in your code you could uh then
00:19:46.559 get yourself a new command that's a CLI
00:19:49.320 command that you could be like
00:19:51.380 SSO create and that on your command line
00:19:55.860 that you can kind of compose those other
00:19:59.220 dependencies together
00:20:01.320 and so like to me that was like amazing
00:20:03.600 that I could make my own command line
00:20:05.700 stuff
00:20:08.220 and so they are just registered just
00:20:10.559 like any object and then you use your
00:20:12.600 depths to compose those together and so
00:20:15.380 these might be things that we really
00:20:17.520 liked you know with your CLI that you
00:20:19.679 already like like rake and DB right
00:20:21.720 migrate uh why don't we just bring that
00:20:24.120 in and we'll code up our own clis uh
00:20:27.299 which Hanami allows you to just tap into
00:20:29.700 what they're doing so all these
00:20:31.500 generators and things that we're talking
00:20:33.480 about that Hanami can do they're
00:20:35.880 actually just the CLI and you can hack
00:20:37.860 it yourself
00:20:40.440 and so these were some of the help
00:20:42.900 regenerators
00:20:44.400 um like you can generate your app which
00:20:46.380 then it has the complete folder
00:20:47.940 structure for you when we're talking the
00:20:50.100 getting started guide that's actually
00:20:51.900 where it starts at is using that Nami
00:20:54.780 new and then create a new hap app name
00:20:57.539 and so it will do that gem file as well
00:20:59.820 as everything you might need for
00:21:01.500 starting up a hananami app and then same
00:21:04.380 thing with sorry dry today
00:21:10.320 so that's the same thing with how you
00:21:12.419 actually create your slice one of the
00:21:14.640 best things is to First reach for the
00:21:16.440 generator and all these generators are
00:21:18.840 actually based on the dry CLI so then
00:21:21.419 they can be hacked or modified for your
00:21:23.700 own stuff
00:21:25.200 oh God I didn't think about that but yes
00:21:27.900 it's a dry day today and I am talking
00:21:30.000 dry
00:21:31.980 and so some of my favorite things
00:21:35.640 the console like any engineer who has to
00:21:39.720 do with deal with a production app has
00:21:42.240 had to do that go into Heroku boot up
00:21:45.419 your uh rails console but it's in
00:21:47.340 production it's probably in a private
00:21:48.780 space it's going to take like 30 seconds
00:21:50.700 you'll like it's boot it up you'll go
00:21:52.620 get some coffee you'll come back
00:21:53.940 hopefully it's loaded up I have my
00:21:56.760 Hanami console with a production app and
00:21:59.460 then I have my Hanami console with my
00:22:01.740 literal app that's on my machine that I
00:22:04.440 just created
00:22:05.460 they aren't that much difference between
00:22:07.620 the two on the booties uptime the slices
00:22:11.520 yeah so we had to kind of tie on it
00:22:13.260 before slices can be their own
00:22:14.880 containers and so that really helps when
00:22:17.340 you think about separation of concerns
00:22:19.440 and your logical databases
00:22:22.380 it's great for apis that HTTP layer is
00:22:26.280 just fast it works with its requests
00:22:28.980 well and as a developer it's easy to
00:22:31.740 create apis
00:22:34.320 and the more I use the depth injection
00:22:37.500 management and that the depth injector
00:22:40.799 it is just makes more sense and I kind
00:22:44.039 of miss it when I can't use it
00:22:47.580 and as well as like the drive CLI just
00:22:49.980 makes it so great to make your own
00:22:52.159 developer-centric tasks
00:22:55.500 uh but there is a couple things that
00:22:58.440 um Hanami could use a little bit
00:23:00.360 Improvement on so ROM so we chatted a
00:23:02.940 little bit about the persistence layer
00:23:04.380 uh currently it does use ROM which is
00:23:06.900 another thing that Tim Reilly is
00:23:08.640 involved in but it's not the same as
00:23:11.400 active record and that's a learning
00:23:13.380 curve especially coming from active
00:23:15.299 record
00:23:16.100 there's not much front-end integration
00:23:18.360 yet so it is brilliant with apis it's
00:23:21.360 brilliant with web services not so great
00:23:23.820 with the front end but that's something
00:23:25.679 that's coming
00:23:26.940 and with Konami since it's so integrated
00:23:30.840 with dry RV you kind of have to have
00:23:33.000 that familiarity with that uh what's
00:23:36.720 going on with your IRB and that
00:23:38.400 functional programming
00:23:40.140 ugh
00:23:48.059 and so this was just a showing in action
00:23:50.220 like what we've done to create some of
00:23:52.559 our own tooling and so we were able to
00:23:55.559 code it up with uh just allowing us to
00:23:58.799 easily generate a whole bunch of stuff
00:24:00.659 for SSO because that was our first use
00:24:02.880 case with our kind of Greenfield
00:24:04.860 development and so we progressed by
00:24:07.200 getting the uh the CLI working and then
00:24:10.140 kind of making it more of an automated
00:24:12.059 thing
00:24:14.940 this was it in action too kind of
00:24:17.580 showing the difference in the boot time
00:24:19.140 which with keeping an app maintainable
00:24:22.740 you have to be able to get into it
00:24:24.720 quickly and so
00:24:26.460 um this was me just attempting to time
00:24:28.080 it so I started it and closed it right
00:24:30.240 away and started and closed it right
00:24:32.039 away and so on the left is actually
00:24:34.919 using the in my full application on the
00:24:37.799 right as just the brand new app that I
00:24:40.020 had just generated and it's not a ton of
00:24:42.419 difference time wise in just booting up
00:24:45.059 that console which as you know in rails
00:24:47.580 the more stuff you have going on the
00:24:50.159 slower your rails consoles can boot
00:24:54.840 foreign
00:24:56.360 this is just kind of showing off what is
00:25:00.240 the test time uh looking like because
00:25:03.600 you know running your full R-Spec Suite
00:25:06.059 is another thing that helps with
00:25:08.100 maintainability is that you need to be
00:25:10.500 able to run that full suite and you need
00:25:12.360 to be able to run it consistently and
00:25:15.120 you need to be able to run it quickly
00:25:18.240 this is one thing that uh these are over
00:25:20.400 the three different slices you can see
00:25:22.740 that I'm in the seconds the most amount
00:25:25.080 of time for a full test Suite run I have
00:25:26.940 is five seconds
00:25:29.100 that's doable
00:25:30.840 our build times are currently averaging
00:25:33.720 about five to six minutes so you talk
00:25:35.940 about how you want it to be integrated
00:25:38.220 on your CI CD pipeline you need to be
00:25:40.980 able to do that
00:25:44.400 and so so far are what we've been able
00:25:47.760 to do in production with Hanami has
00:25:49.740 worked wonderful but we also did kind of
00:25:52.980 build our use case around what we wanted
00:25:55.200 to be we needed apis and we wanted them
00:25:58.380 fast and so Hanami has been working well
00:26:01.020 for that
00:26:02.340 okay I'm way over my time so sorry but
00:26:05.880 uh thank you so much wmb I did want to
00:26:09.600 uh say my teammates are the ones who
00:26:12.539 really helped me understand this quite a
00:26:14.340 bit uh Adam lassic is actually uh
00:26:17.039 helping out with uh different
00:26:19.440 um contributions to an army itself and
00:26:22.140 Andy and Jim and Miguel are amazing
00:26:24.059 teammates
00:26:25.559 I have a ton of links for you all I will
00:26:28.559 be sure to share share this out Hanami
00:26:31.020 has some really great guides as well as
00:26:33.299 the documentation itself is where I got
00:26:36.000 the majority of my information at
00:26:38.700 also I have a style a design guide
00:26:41.340 because design matters
00:26:45.480 me
Explore all talks recorded at WNB.rb Meetup
+21