Matt Raible is a well-known Java and JavaScript educator with several books to his credit and broad experience in the industry. He is currently developer advocate at Okta, where he focuses on security, and a member of the technology advisory board of JHipster, a leading hybrid Java and JavaScript development platform.
JHipster is essentially an advanced build tool that streamlines the development of full-stack applications that use reactive front ends. It uses Spring Boot on the back end, supports React, Vue, Angular, and other JS frameworks on the front end, and includes scaffolding for both JPA-based relational datastores and NoSQL datastores such as MongoDB and Cassandra. You can read my walkthrough of JHipster here.
I had a chance to chat with Raible about JHipster, Java, JavaScript, security, monoliths vs. microservices, cloud infrastructure, and more.
Matt RaibleMatt Raible
Matthew Tyson: You’ve been helping people learn about coding forever. You’ve done a lot of Java evangelism over the years. Now you are talking quite a bit about JavaScript and JavaScript frameworks. What brought you to look more at JS?
Matt Raible: JavaScript was my first love. I’m one of those programmers whose first language was HTML. Back in ’92. I learned JavaScript and CSS shortly after and started building websites. I didn’t start learning Java until ’99.
Even though Spring and back-end development was cool, it wasn’t my true love. That’s always been UI. I got back into UI development around 2007-2008, and I was a “UI Architect” for several clients until 2016.
In 2016, I was working for CA doing JS in the morning and I had another contract with Stormpath doing Java in the afternoon. Stormpath tried to hire me full-time as a Java developer and I told them, “No, I don’t really want to do Java all the time.” Our negotiations stalled for a couple months. Then I wrote up a “dream job” letter and sent it to them. This involved being an advocate (blog posts, speaking, etc.) for both Java and JavaScript.
Tyson: You are on the tech board for JHipster, which as a union of Java and JavaScript sounds like an excellent convergence of your interests. Can you tell me how you got involved in that project and what is exciting about it?
Raible: I stumbled upon it in the summer of 2014. I was working for a client that built a rapid prototype of an API and UI with Python using a framework that made things easy (I forget which one). I thought I could do the same in Java, found JHipster, and delivered a similar prototype in under 24 hours. I was impressed! And first impressions are lasting.
I’d been an independent consultant for most of my career at that point, and I knew that marketing was important. I was traveling to speak at conferences every so often, but I knew there was power in authoring a book too. So I talked to InfoQ about writing the JHipster Mini-Book and they agreed to help.
In the process of writing the book, and creating the sample app for it, I found bugs and entered issues. Some of them I was able to solve myself and submitted PRs. After doing this for several months, I was invited to be a committer on the project.
Then I came up with the idea of dressing up as an old-fashioned Java developer to start a JHipster talk and gradually changing into a Java hipster as the talk went on. I did it first at the Denver JUG in April 2015. My best performance of that talk was at Devoxx Belgium in 2015.
When I joined Stormpath, and later Okta, I decided one of the best ways to be an effective developer advocate was to integrate the company’s product into JHipster. Then I could keep writing and talking about JHipster and demonstrate the company’s product at the same time. It’s worked out quite well and now Okta is the platinum sponsor for JHipster! We contribute $2500 per month.
Tyson: You know as I was looking at JHipster I saw the out-of-the-box auth support and thought, “Oh thank God.” As a dev I hate auth, like here I go again doing the same thing over and over…
Do you mind talking a bit in detail about the auth support in JHipster and how it integrates with Auth0/Okta?
Raible: When I first started integrating auth into JHipster, it was via the Stormpath module I created. Since Stormpath used an embedded setup at the time, the integration mostly involved adding the Stormpath SDKs. You can read more about it here.
Then, Okta bought Stormpath in February 2017. Because we shut down the Stormpath API in August 2017, this module was no longer useful. In September 2017, I started refactoring JHipster’s OAuth implementation. You can read about most of this effort in the following blog post: Use OpenID Connect Support with JHipster.
JHipster’s OAuth implementation at the time involved using an authorization server from Spring Security and putting the client ID and secret in the client-side code. This was a huge security hole. Over the course of a month, we refactored everything to happen server-side and never store tokens on the client. Five years later, I still think this was a good decision.
Tyson: I talk a bit about hitting Auth0 from a Node.js context here. I feel like we have come a long way in making security less burdensome and more developer friendly. What do you see as trends or directions the space is moving in?
Raible: I agree, but I think we have a ways to go.
I like to compare security to testing. Most developers know they should test and there’s lots of tools to show test coverage. Most IDEs even have support for showing test coverage of classes. There isn’t a whole lot in the security space as far as IDE plugins to point out security issues to developers. I do think things are improving though. Snyk has an IntelliJ plugin for fixing vulnerabilities. You can do OWASP checks with Maven, and GitHub’s Dependabot is pretty slick.
One big problem I see is developers (or their clients) wanting to implement SAML instead of OIDC. To quote my friend Joël Franusic, “SAML is to OIDC as SOAP is to REST.” I don’t see a whole lot of folks implementing SOAP APIs, so why are people still implementing SAML? I don’t think this is the fault of developers, but misinformed decision makers.
Regarding developer friendliness, when I first met Trish, back in 2010, she was a salesperson in the security industry. I traveled to a cybersecurity conference with her in Kansas City. She introduced me to some of her infosec friends. When they asked what I did, I said “I’m a developer.” One of the first responses was, “I bet I can hack your shit.” This was alarming to me.
I thought, “Hey, we just met and you’re already insulting me?!” From that moment on, I started looking into doing more security-related talks to try and make security more friendly to developers. I’ve done similar talks in the past explaining JavaScript and web technologies to Java developers to try and help them embrace web technologies rather than ignore them by using JSF [Java Server Faces].
Tyson: Yikes. It seems that if you spend a lot of time focused on hacking, you can break stuff, and if you don’t, you’re vulnerable to those who do.
Can I ask about the Spring Native/JHipster stuff that recently came out? What is the main takeaway there?
Raible: The main takeaway is that you make your JHipster + Spring Boot app start in milliseconds instead of seconds if you integrate JHipster Native.
We have blueprints for Micronaut and Quarkus too. They have native support built-in, but we need to do some work to make them work with JHipster.
There’s also blueprints for NestJS and .NET Core, but they don’t have any kind of native support.
JHipster Native (and Spring Native) will likely be only temporary because Spring Boot 3 plans to have native by default. Once we upgrade to that (its release is scheduled for the end of 2022), we won’t need JHipster Native anymore. Of course, existing apps based on Spring Boot 2.x will still need it.
Tyson: You’ve also written quite a bit about infrastructure—microservices, Kubernetes, etc. What’s your sense of where things are headed there? Any interesting trends or developments?
Raible: I like Kelsey Hightower’s post from 2020 about how monoliths are the future. I think there’s a lot of interest in microservices from developers because they want to learn about all the things that make up microservices, build their résumés, and use the latest “hip” technologies. However, in my opinion, there’s a lot of times that a monolith will work just fine. Where monoliths break down is when you have a ton of people working on it and you need to scale people and the ability to push code quickly without waiting on others.
Microservices are often hindered by Conway’s Law in that your organization needs to have the ability to create product teams that can come up with ideas, deliver them, and maintain them independently. If your organization has the ability to do that without relying on others, then there’s a good chance adopting microservices will work out well for you.
Scaling a monolith usually isn’t a problem, it’s scaling the people. When I worked at LinkedIn back in 2007-2008, they had a monolith and it performed just fine. However, they only deployed on Thursdays and that was a problem for velocity. They eventually adopted microservices because of their people-scaling problem, not because of technology-scaling problems.
I don’t have a good sense of where things are headed, but I do believe Kubernetes requires a lot of low-level YAML to make things work. I can’t help but think there’s a better way to configure things. Ideally, there would be some sort of syntax that’s easy enough to memorize. Or maybe there will eventually be something like JHipster that can generate all of the YAML for you.
Tyson: Super interesting. Would you expand on how scaling people is a bottleneck? Kind of describe what it means a bit more?
Raible: All companies are technology companies these days and chances are they have developers. The larger the company, the more developers it tends to have, or outsource to. If they’re all working on the same project (aka the monolith) and are committing thousands of lines of code per hour, there’s bound to be conflicts. It turns into a merge nightmare when releasing. However, if you have thousands of developers and there’s teams of less than 10 that work on hundreds of microservices, there’s less likely to be conflicts. Also, with microservices, you should be able to deploy independently and minimize the dependencies between teams.
Funny related story: When I first heard James Governor talk about how when web companies grow up, they turn into Java shops. I once thought this was because Java was a better language and static typing made scalability easier. After hearing one of James’ talks in person, I learned it’s more because Java has the largest ecosystem of developers. When you’re trying to hire hundreds of developers at a time to scale your business, it’s one of the easiest to hire for.
Tyson: This is great stuff! OK, one last question to wrap up. I’m curious if you have any reflections on the coding life, as a developer (like myself) who has been around long enough to look back on things a bit.
Raible: It’s been nothing short of fabulous! I went to school at DU [University of Denver] when we used Pine for email and Lynx was my first browser. Seeing the internet become visual with SlipKnot and then Netscape 1.0 was incredible. I started using Struts 1.0 right after it was released, loved it, and became heavily involved in its community. I was rewarded with lots of new friends and solutions to problems I faced. Then came blogging, AppFuse, Spring, my book on Spring, speaking (inspired by Bruce Snyder), the JavaScript renaissance, and my dive back into UI development.
The thing I’ve enjoyed the most about the whole ride is the friends I’ve made in the open source community along the way. When you go to a conference and get to hang or hack with someone you’ve known for almost 20 years, it really is special. My ability to work remotely since 2002 has been a real blessing too. I love having the freedom to work from anywhere that has good internet!
Tyson: Thanks Matt, it’s been great catching up with you!
Raible: It was fun chatting with you!
Copyright © 2022 IDG Communications, Inc.
