Ep. #70, JAMstack Consulting with Núria Soriano and Josep Jaume of Codegram

Brian Douglas: Welcome to another installment of JAMstack Radio.

On the line, we've got Nuria. Hey Nuria.

Nuria Soriano: Hi Brian, how are you?

Brian: I'm doing fine. Thank you. And also Josep as well. And I hope I got that.

Josep Jaume: That's pretty close, yeah. Hi, Brian.

Brian: Yes. So thanks very much, for both of you calling in all the way from Barcelona or close by.

Maybe you're in a neighborhood outside-- It doesn't matter, we're not trying to geo-locate you.

But you both work at the same company, which is Codegram.

And I'm super happy with Codegram because I've been working with you for, I guess, eight months now, maybe a little longer than that.

Just first stuff with GitHub, but Codegram maintains a static site generator called Gridsome.

So I want to talk about that, but who wants to give the introduction to what Codegram is?

And then we can jump into the code itself.

Josep: So, Codegram. We are an end-to-end digital agency and there are three founders, one of which is me actually.

Right now I'm head of engineering for a 27-people company. We've grown a little bit in the last 8 or 9 years.

Brian: Wow.

Josep: The company is probably 10 years. The first year was just messing around, so yeah, 8 real years.

Brian: I think it's similar to GitHub has one not real year where they were just tinkering around with the idea, and then finally created the actual proper company.

But anybody can go back and look at GitHub and look at that story somewhere.

I'm not sure where that lives, but I'm curious, our relationship started from Full Stack Fest, which Codegram actually runs as well.

So I guess what's the--? Josep, you were in the background a lot, helping out with that event. What's the purpose of that, and why Full Stack Fest?

Josep: The story is that we started as a Ruby shop and I mean, we went and we were going to many conferences back then and we thought that maybe Barcelona would have the interest.

So, we just did one. We didn't know anything about how to run conferences and it worked out pretty well.

Over the years we, as a company, became more interested in many other technologies.

So eventually we figured out, after passing by a small conference called Future.js, we figured out that maybe a Full Stack conference would be more interesting to many people.

This year, unfortunately, we're not going to have one for obvious reasons.

But our goal has been for the last, I think, four years we have-- No, 3-4 years. No, four of them already, sorry.

We have been focused on providing inspiration for all kinds of developers, more than actual knowledge.

We're looking to throw a conference that inspires people other than just lecturing them, which is what we think makes a conference valuable.

Brian: I would say the content was exceptional. The speakers that you brought out to Barcelona was great.

You had Node team members, TC39 members, Sarah Drasner was there as well talking about a lot of animation awesomeness .

Even Angie Jones talking about automation too, and that talk blew me away on all the stuff I don't do properly, which was an excellent talk.

So even though you're not having a conference this year, everybody can go back and look at the videos on YouTube, I highly recommend it.

So Nuria, your title is senior engineer within Codegram. Is that correct?

Nuria: I'm the tech lead, actually.

Brian: Tech lead. OK, perfect.

Nuria: I started as a senior engineer two years ago, but since earlier this year I got promoted to tech lead.

Brian: Awesome. Congratulations.

Nuria: Thank you.

Brian: So speaking of tech leadership. My interactions, you've been working on a project for us which was built in Vue.js and it was powered by a static site generator called Gridsome.

Are you able to provide some context around "Why Vue?"

And also, "Why build your own framework around a JavaScript framework that already exists or a library?

I don't know if you want to split it down the middle like that, but go ahead.

Nuria: OK. Well, just to mention, I think earlier you said that we were maintainers of Gridsome.

We are not. I just want to make that clear. We have contributed, but yeah, we are not the maintainers.

Brian: Gotcha. I guess I just assumed, because you introduced me to Gridsome.

Nuria: Yeah, we really like it.

Brian: Excellent. Well even better.

Nuria: So, Codegram started working with you when I entered the company because I was such a fan of it and yeah, I just find way easier to work with Vue then React or Angular.

All of them are good frameworks in their own things, but I really like that Vue is just like HTML, CSS and JavaScript.

You need to learn a bit how the framework works, but for me it's easier than understanding JSX or Typescript and all the--

It's easier to start working with it and it's really easy to develop things fast and it scales well.

Also, Vue offers all the state management, routing, and all that.

It's part of its core libraries, so it's all really tied together unlike maybe React that you need to use third-party solutions that sometimes don't work that well together, especially when there's a version switch.

Brian: I think the biggest one that I can think of with the version switch is the React router and the React router dom, and trying to figure out which and when, and how to migrate it.

I know we've figured that out in the later versions, how to do that properly, but that's always been a point of contention for me when it comes to upgrading my projects.

But I'm right there with you, when it comes to picking up a solution and having all of the opinions done for you--

Which you had mentioned, Josep, you started as a Ruby shop.

Did you also do a lot of Rails stuff and Sinatra as well?

Josep: Yeah, of course. Back there you couldn't even distinguish both.

It was difficult even for me in the very beginning, you know, "Where does Rails end?"

Brian: I could see the attraction to having those opinions coming from a Vue or even Gridsome, because with Rails you don't need to know how networking works.

You can get something done pretty quickly and you don't have to know the ins and outs, even today, of accessibility.

Because it's built in with the framework and you get that for free, so it sounds like with Gridsome you get some pretty cool things out of the box too as well.

The project that we worked together on was GitHubHackathon.com.

This project was powered by Gridsome, and the nice part about it is that I didn't have to write all the code for it.

For me, I had never worked on any sort of production level Vue code.

I worked on one prior Vue project, but it was a lot of boiler plate that was already given to me by the time I started touching it.

So navigating it was very limited, and the UI itself was done so I never touched the UI.

It just happened to have Vue there, and I just had to learn how to get the front end to run with Rails, and that was about all I did.

So this project, the hackathon, I was actually able to manipulate it and change things and update copy with pretty low effort.

I didn't have to try to figure it out.

So I'm curious of, maybe Nuria, if you want to talk about how the project was structured and how we powered it by actions and how you made those decisions to basically check all the boxes for us?

Nuria: So, it was really fun working on the hackathon.

The project was built with Gridsome, that is a static site generator built with Vue.

It's like Gatsby, like Gatsby from React.

It's like the same thing, you have that GraphQL and that layer and your data can come from files or from external APIs or headless CMS.

It works pretty much the same.

I guess people are more familiar with Gatsby, so what we did is we wanted the hackathon to be a static site because they are fast and CEO friendly and everything.

So all the submissions that people send to the hackathon were actually JSON files that were stored in the repository, and Gridsome gathered all these files and using this data layer was deployed statically every time that the new submission was added.

The cool thing is that the submissions were actually-- When a user submitted an action, filled the form and had hit the submit button, this triggered a hiccup action. A workflow that added the JSON file to the repository.

So the GitHub Actions Hackathon with GitHub actions on the back end, and that was a nice touch, even though the repository was private and people couldn't see.

But it was really nice doing that, and it also has the good points that when a submission was high, the pull request was open, and then we had a series of other workflows that validated these action.

Like, that it had the YAML file that it had license, stuff like that.

Then from the GitHub side, we're able to reveal these submissions as a pull request as you go with Go.

So everything was really developer friendly, and the reason was it was really easy to work with.

I think you found that out, all the components are really easy to manage because of the HTML and CSS and everything. It's clear.

Brian: It also gives you like the name base type routing as well out of the box, which was exceptional, because the site itself was pretty forward thinking but also the structure wasn't too crazy.

There was a login, there was a submission form, there was a "Thanks for your submission" page.

So all that being based on the names of the routing was super easy for me to navigate and make changes.

Some of the changes-- Actually, I want to talk about this too as well.

Your experience with GitHub actions, because I don't think maybe Codegram had much experience of actions prior to that. Was that correct?

Nuria: Not much. We did the typical things like Lints action for your request under deploy actions.

But that was the project that we really used, we pushed the limits of what you can do with GitHub actions. That was fun.

Brian: You definitely did. Going back to that, one thing that we--

We had shipped a feature for actions, and I don't know if you realize this during the process of us thinking about the project and me pitching the original idea of leveraging actions, the power of the Action Hackathon, which was repository dispatch.

Which is the way that we ended up leveraging serverless functions, so that'd be able to submit the form, or even submit the form but also confirm login through the GitHub token and make sure that was secure.

That was not a feature we had even months prior to that event, it was actually shipped within the idea phase of the event, which was kind of clutch when you started to think about it.

Because we were able to talk to the serverless function and then when the serverless function confirmed the identity of the person or confirmed and validated the submission, they can then send it back to the GitHub repo that was powering the hackathon and then trigger more actions, which was pretty amazing.

Quite honestly, y'all figured that out for us.

I don't know if I saw any other public uses of that actual feature repository dispatch and that flag prior to that, so we were pretty early on the adoption train.

Nuria: Cool. That was the key to everything, because without the repository dispatch I don't know if you could have connected the whole thing.

Brian: The one thing that was really appreciated too as well with this project, Josep, when we originally started having the conversation was the fact that we made this a JAMstack project.

Mainly because for obvious reasons JAMstack is pretty close to my heart.

It's the way I think and develop my projects, but being able to have that structure and leverage essentially 100% of the backend was GitHub.

If that wasn't clear, Nuria explained that we had JSON files and that was how the submissions were presented with a PR being open for the JSON file for the project, but it was an amazing experience.

I was just blown away. We were blown away internally too, because I wrote a couple internal posts.

We do have a post that's on the Codegram blog, the whole case study too as well, so I do encourage listeners to check out the blog for Codegram to find out more about that story and figure out how we dissected this and made this work.

But I'm curious, with Josep, from your high throne as a CTO and co-founder of the consultancy, how do you see JAMstack and the consultancy side, are you seeing good adoption for individuals who want their project shipped pretty quickly and have security and speed, and all the above?

Josep: Yeah. I mean We've worked in many JAMstack projects already, specifically statically generated sites.

And one of the reasons I like to point out to the clients is that I can guarantee that the site is not going to be brought down.

Some people won't believe you. For example, we did a website for the Davis cup finals, the tennis tournament.

And they were really worried about this possibility that when the event happens, how will you make sure that the host sites were not going to be brought down?

Which is their experience had been with WordPress, for example.

That's one of the best selling points you have, like it's impossible.

It's on a CDN. You'd have to bring down Amazon or something.

Brian: Which only Amazon can do.

Josep: Yeah, exactly. In general, from a development standpoint, it's also quicker to get from A to B.

Deployment is super easy with Netlify or with GitHub pages and whatever.

So in general, the feedback loop to get something shown to the client is quite short.

That's if I can add another selling reason, so we can build whole interfaces without having to care about the back end at all with this iteration.

So we can split teams and work separately in a very effective manner. There's many reasons we love that.

Brian: It's interesting. I wonder, the engineers at Codegram.

Do they specialize in the front end and specialize in the back end? Or is there a lot of floating back and forth?

Josep: We have a bit of everything. People who are more front end than back end, and there are people that hate CSS.

I'm not amongst them, I love CSS actually.

So we have a gradient, but the thing is that everybody knows -- Especially with a JAMstack approach, you can build a GraphQL API without having to care about how the data is going to be consumed.

So usually we put people in one side or another, some of them like Nuria are working on both parts.

Nuria: But generally, people tend to lean more to one side or the other.

Like I do both, but I'm more of a front end and someone will be the opposite.

Brian: I would say it like this, the term "Full stack" is quite evolved even in the eight years, probably, since Codegram has been around.

Because I think the full stack, it's knowledge of all parts, but it doesn't mean expertise in every area.

I like CSS as well, but I'm not great at it.

I might take a little too long on certain things but that's because I like perfection, but also I don't know what I'm doing.

But also when it comes to provisioning APIs and stuff like that, that's something that I'm just not-- I tend to lean on existing frameworks and projects to get that to work for me.

I could do it all, but I probably fit more in the middle when it really comes down to it.

Like Hemi, some Redux layer or some database layer that talking to your UI and make it connect and make the data work.

That's really where I sit, but I wanted to transition and go back to talking about the difference between Vue and React, because you brought a really good comparison of standing up Gridsome and Gatsby.

I think that for those who haven't touched Vue yet and maybe only have done React, you understand the context of Gatsby and Gatsby being very rich with plugins.

I think that's really where their claim is, and where they're cornering the React framework market.

So I'm curious, does Gridsome also have a very rich plugin ecosystem as well?

Nuria: Yeah. Obviously it's not as big as Gatsby, but I think it has enough to do most projects.

We've never found something that we cannot do with Gridsome.

We also use it for our corporate website, and there were some points with internationalization, but we found a plugin and then we contributed to add the missing features that we needed.

Even though it's a smaller community, it's a smaller ecosystem, I think it's enough for most projects. It's also a really good opportunity for contributing to open source because there's a lot to do.

People appreciate the help there because it's a small community , so I encourage people to use it and contribute.

Josep: I've seen even some people talking about that there must be a way to make them compatible, Gatsby and Gridsome plans, because the main obstructions aren't the same.

Sources and transformers, data sources and ways to conform that data into HTML or whatever.

So yeah, that would be great because right now there's a lot of redundancy on the Gatsby and Gridsome ecosystems and it's mostly the same.

Brian: I think it's just in general in JavaScript, there's a bit of redundancy.

I think as the ecosystem matures, you see things like testing where there were a ton of frameworks.

First there were zero frameworks, like I hardly ever heard people talk about JavaScript testing, and then we started growing into a place where we had too many of them.

I think now some of the more established ones and the ones who stood the test of time, and the test of time being one or two years at JavaScript, now we see the go-to ones.

I think the same thing with the data layer.

When it comes to GraphQL, there's only a couple options that you probably want to leverage when you're leveraging GraphQL.

I think that's OK, and I think that having a stronger community in one way or the other, it helps.

Because when you don't have to ship the same solutions over and over again and you can leverage community for like Codegram, it sounds like you could basically have solved solutions and help power the apps that are essentially making you money as a company, but also the opportunity to give back. It sounds like a win-win if you ask me.

I am super pleased with the Gridsome decision, and I like Gatsby and I like how that structure is.

I'm curious of the comparison to Nuxt too as well, because our current project that we're working on today which will go unnamed is using Nuxt.

So I'm curious on the structure, and how you think through comparing Gridsome to Nuxt?

Nuria: So, Nuxt is a way bigger and more established framework.

We tend to choose it for bigger projects, more complex projects, and that's going to be used for static sites but also for server side rendering.

Which for this current project was something that we were thinking that maybe at some point it would be useful to have, and it would be easy to switch from a JAMstack to a server side generation in case it grew a lot.

Nuxt offers this with way more flexibility, and obviously being more established it offers a bit more security than a smaller project, that you don't know where it's going to be in two years.

Although I really like Gridsome, but both are for way different things.

Josep: One of the interesting thing about Nuxt nowadays is that they are trying to go a little bit into the Gridsome space.

Brian: Interesting.

Josep: So they have released a new way to build fully static websites, which wasn't possible before.

You could generate static websites, but then when you switched pages you would use the client side navigation.

So you would keep the API, and now they changed that. So it's more similar to Gridsome than ever, and some things are really amazing about that.

Sometimes not having to deal with GraphQL is a bit more comfortable, at least if you asked me.

It's really interesting to see where they go next and how will that Gridsome react.

I saw some tweets actually from the Gridsome people saying, "Hey, it's good to see that Nuxt is catching up with static generation because we were there all along."

Brian: If you see Next, which I think Nuxt was originally modeled after, which is Next.js, 9.3 was the version earlier this year where they have static generation as part of the feature suite when it comes to the thought of Next.

So I think it's very similar where, it's funny that we can basically compare with the React and Vue ecosystem with two different projects in each one of them.

But Next and Gatsby tend to get compared a lot, a nd so it seems like Next is also entering the Gatsby space when you start thinking about static generation.

I actually just built a Next app last week for a Stripe store to sell stickers.

I'd give the URL, but I'm not confident of the way I've set it up, so I might have to redo it.

So I'll share it next episode.

But what I'm getting at is that it was pretty seamless to be able to ship it to Vercel and have it on now as a server rendered app, but then also take it to Netlify pretty easily just by using a different command.

So, I'm a big fan of using one solution to do my statically generated sites.

But also, if I need a server, the cool thing about Vercel is that you could also do functions as well.

I'm not sure when they shipped that, but you could also leverage functions to power your JavaScript as well, just built within the product, which is quite amazing.

But yeah, I'm all for growing up the ecosystem, growing of the space, enhancing the jam as well.

That's one thing I'm also a big fan of. I'm curious, is there anything else y'all want to talk about before we transition to picks?

Nuria: Just to mention that what I think Gridsome, or Gatsby, are really cool about is when you actually want to deal with files and you want your data to come from files, or even if you want to mix from APIs and files, you can create your own custom taxonomies to relate those different pieces of information in a way that with Nuxt or with Next would be I think harder.

Gridsome just gives you the tools to do that. We built the blog for our site and we are able to link with tags, and with these tags we matched with a Kaiser studies, and all of those are just Markdown files and they are all related to one another without actually having to create-- I don't know how I would do that with Nuxt though.

Brian: A database, or something. I guess maybe even JSON, maybe, which is not as nice.

But I agree, we actually completely overlapped that thought too as well.

The idea of the structure, when you think of a marketing site that maybe is going to have basically GitHubHackathon.com, though I wouldn't call it a marketing site it basically is.

Where it only has the three different pages, and those three different pages is going to be static content that perhaps a marketing team is going to go in there and update Markdown files to edit that copy.

I think that's actually powered by YAML.

But regardless, if it's load changing interactions for a site, it makes sense to reach for a Gridsome.

If you want to power some things with the server and have that all in house within the repo, maybe Nuxt sounds like a thing to reach for.

Like, if I was building GitHub.com, I would not choose Gridsome.

I'd probably choose Nuxt. So maybe if that distinction is helpful for people. Does that make sense?

Nuria: Yeah. Totally.

Brian: Excellent. So I'm going to transition us to jam picks.

I appreciate the conversation around Gridsome, and even spilling into Nuxt and talking about Next.

Hopefully I'm annunciating that properly-- Nuxt and Next, because those are way too close of words.

We have lots of listeners across the globe, so I haven't gotten a lot of complaints over my American accent, but we'll see. Definitely tweet at me.

Josep: If I can add something about this Nuxt and Next thing, I actually tried to start the project with Next, after working with Nuxt for quite a while, and I found it really frustrating.

It looks to me like it lags a little bit behind Nuxt, the new version.

Brian: Really? Interesting.

Josep: It feels to me like Nuxt is way more polished and well thought than Next, which sometimes it takes you like through this path where you have to actually spin up, I think it was Express the route and whatever.

It's a little bit more confusing to me, at least.

Brian: Interesting. I've not really dug into Nuxt too deeply, other than the project that we're currently working on, but I'm intrigued.

I might actually pick my next project, a little side project doing Nuxt, just to compare for myself.

I'd also encourage the listeners, as a nice little exercise, let us know which version of Nuxt/Next do you like.

Josep: I hope I don't get hate for this, sorry. But I felt it was worth mentioning.

Brian: Please, all hot takes to Josep.

Nuria: No, I get this feeling a lot with Vue in general and with Gridsome and all the pieces of Vue.

Since they are usually built later, React ecosystem always leads the way and then Vue maybe follows behind.

It also goes ahead with other things, and I don't mean it as a bad thing, but it actually helps it being more polished I think and gathering the good ideas from the React ecosystem and improving on them.

So I get this feeling a lot in general, working with Vue.

Josep: I agree with that. I think that the way that React started, probably with a functional mindset, compositional, wherever.

It tends to create more chaos than Vue, that it's more ergonomics first.

For me, I love React. I think it's amazing and there's lots of things on there that make React really powerful, but it feels like the far West to me sometimes.

Like everything holds together a little bit poorly while in the Vue ecosystem, everything it's straight forward, I think. It's easier to grasp.

Brian: Even things like handling like a JWT and passing that through the app and making sure I have access to-- Like, "Am I logged in on this page or not?"

That can be challenging in React, especially because it seems like the ecosystems moved away from things like Redux, which made that easy.

But Redux was a big lift to opt into and I have done many a talks on how I produce apps and eventually add Redux, because I always push it off for the end.

But with VueX it seems like it's embedded in the idea of Vue, and it sits real nice, and you don't need to take an entire engineering week to make sure that that VueX is going to work.

Which is not a knock against React, I know we're all dancing around trying not to start a framework war in the conversation.

But it's actually pretty relevant too as well, because I think in business, at least in American business, a "Second mover advantage" is a term that people cite a lot. Which is basically the first person basically just figures it out, but then the second person gets to figure out how to do it faster and better.

Not that React is doing everything wrong, but I think React definitely does feel like more of an--

If I was a pure JavaScript person and I liked to use the map function to iterate over my list, then that's ideal.

I think React is great if you want to learn JavaScript really well, mostly maybe you might learn some bad things, but other than JSX that doesn't really put a lot of stuff in front of your JavaScript code.

I would say the same thing with Vue too as well, it's just a different flavor, and I think we've elevated and identified different reasons to choose one or the other.

It really comes down to community and participation and being able to have access to tools as well, but that was a great little spurt of conversation too as well. I appreciate that.

Josep: There's Vue 3 around the corner, so just keep an eye on it.

I think it's a couple of weeks until they release the final version, and they've worked out a lot of ideas from React, so worth checking out as well.

Brian: Excellent. All right, so I now will transition us to picks.

These are jam picks, things that we're jamming on that keep us going.

Could be music, food, whatever related.

I am going to give one pick, actually two picks.

First pick is going to be Sam Selikoff. Sam has a YouTube channel, I highly recommend it.

He just started I think since COVID shelter in place started, and it's excellent in content.

Sam is somebody I know from Ember, Ember being the JavaScript front end framework.

He did a lot of work there, he built a project called Mirage which is a really cool tool for mocking your data for testing.

So check out Mirage, check out Sam's YouTube channel as well, and then I just want to give a quick pick.

Which I'd actually given this pick tons of episodes ago, but The Morning Bun is one of my favorite things right now.

My bakery shut down during the early parts of shelter in place and has reopened, and they provide morning buns, which if you don't know what a morning bun is just Google "San Francisco morning bun."

They're amazing. It's like a croissant and churro mixed together, and that's probably a horrible example but just Google it.

Those are my picks. How about Nuria, do you have a pick?

Nuria: Yeah, it's actually nothing new but the other day I re-watched the Matrix.

It's a 20 years old movie, but I recently watched an interview with Lilly Wachowski and she was explaining that the Matrix is in fact the trans allegory, and I never thought about that.

Then I started reading about that, and then watched the movie, and from that point of view it was really interesting because I had watched it several times but it never occurred to me that it could be about that.

It was really eye opening, and the movie has aged very well. It's 20 years old and it doesn't even look like it. I recommend to do that.

Brian: Awesome. I've got a lot of free time these days, I'm d efinitely going to--

Actually with that lens, I would love to watch it again and just pick it apart.

Also, you said there was an interview or a documentary. Is that linkable somewhere?

Nuria: Yeah, it was an interview. It's on YouTube. I will send you a link.

Brian: OK, excellent. Yeah, I'll put that--

Hopefully it'll make it in the show notes as well. Josep, do you have a pick as well?

Josep: Can I do a technical pick?

Brian: Yes. Go for it.

Josep: I was wanting to pick LifeView. LifeView is a library on top of Phoenix and Elixir, which is actually the exact opposite, I can think of to anything JAMstack created.

Brian: OK, excellent.

Josep: It's a highly stateful back end thing where you store your component states, your build component states on the backend.

So it's exactly at the other end of the spectrum.

Brian: To invert it?

Josep: Yeah, and I think it's worth checking it out. It's super interesting.

Brian: OK, Excellent. It sounds like the backend developers are trying to take back some of their turf.

Josep: Yeah, it is exactly. It is a war happening.

Brian: Excellent. Well before that war starts, let's just slide out of this.

I just want to thank you again Josep and Nuria for coming and chatting about Vue and Gridsome, and having a really good conversation on comparing that, even to React as well towards the end.

So I definitely appreciate it, and everybody can check out your work on Codegram, find you over the internet.

And listeners, keep spreading the JAM.