GitLab Incubation Engineering, 12 Nov 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Incubation Engineering Jamstack -- Weekly Demo November 12th 2021

Description

MR Source Editor: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/72764
MR Onboarding Page: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/73183
MR Metadata property: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/73551
Community Survey Key findings: https://gitlab.com/gitlab-org/incubation-engineering/jamstack/meta/-/issues/12
Community Survey (full results): https://jamstack.org/survey/2021/

A

Hi and welcome to the jamstack incubation engineering update um spent the last week almost entirely updating existing mrs one of them is the source editor extension for yaml files. That may potentially have a bigger impact beyond pages, so it's really important to get it right, but it takes a little longer than expected that mr in turn is a precondition for the pages onboarding wizard that I've talked a lot about in the previous updates once the source editor extension is merged. I would like to start the review on that one.

A

So I've put in more work on it to get it from this prototype kind of state to something that can actually be merged.

A

As part of that, I added another, mr- that adds a property to pages metadata table indicating whether the onboarding is complete.

A

The reason is because the onboarding wizard could be done and complete, but the pipeline that deploys the pages may not be finished or may not be successful, and as long as that pipeline isn't successful, the page's deployed property is false. Currently, this page's deployed property is what I use to identify whether or not to display this onboarding wizard.

A

The new property, however, would be set true once all the steps on the wizard are completed, but before pages is actually deployed. um That means we can now show this helpful splash screen in case yeah onboarding is complete, but the pages pipeline isn't yet finished.

A

So this would be all for the what I did update this week, um but I think we have a few minutes to spare. So let me just dive a little deeper into something that didn't make the cut in an early update, because last month in october, was the jamstack conf and, as part of that, netlify published the very interesting jamstack community survey, even with the caveat that the survey respondents are for the most part, netlify uses, I found this such a valuable resource.

A

I took the time to summarize the most important findings as they relate to what I do here at gitlab check it out number one is the purpose of jam stack sites like what kind of applications run on the jam stack, the biggest applications obviously or the most common applications are personal blogs or portfolio, but on number two is already b2b software, um e-commerce, consumer software and informational pages.

A

Gitlab pages is currently very focused on documentation and and software. So I guess we have a huge market untapped. As of yet um the same thing uh very interesting. The traffic of jumpstack sites like how many users do jumpstart sites have and again we're looking at thousands of users, I think for for smaller websites um the the performance improvements that jam stack offers aren't as important um and for millions of of users, you probably look are looking at legacy um applications.

A

um What kind of industries uh are jamstack sites located? In um and again we see a lot of non-technical industries like advertising, marketing, education, finance, media, business, support and logistics, health care, entertainment. So, there's there's a huge um tale of applications that aren't targeted currently by what we do with gitlab pages. I'd say we're mostly focused on on more technical clients.

A

With what gitlab pages does, uh I think the most interesting bit of the whole jumpstart community survey is what technologies are developers jumpstart developers using, and what should we experiment with and and look at supporting, especially in in terms of software languages, I mean javascript is the top used language, obviously, because it's front-end, mostly but very very popular, is also typescript. um The adoption is already huge at almost 60 percent of users or respondents.

A

um But if you look at the satisfaction score, people are extremely happy with typescript, which is very interesting. um So if we have this relation between satisfaction, score and usage, um we can identify up-and-coming um languages and technologies so uh with a low adoption, but high satisfaction score. That is something that we should be looking at um because it might develop into into a very interesting um set of of languages in the future. um So in this area we get have uh go swift, uh rust and elixir, which is um which is very notable.

A

um So if we look at the the popular frameworks that is a very interesting chart, we can see that react has an adoption at about 70 of all developers that responded to the survey, um so that is huge and it's still at a very high satisfaction score in in this area. We have a wide adoption and still a very high satisfaction score.

A

So one of them is next js, which is basically building on react, and it's a server-side rendering engine for react, and here number five is view js in the up and coming area with a low adoption, but high satisfaction score. The highest satisfaction score really has a bit, which is a build engine um that is intending to replace things like webpack, um so it is always been held for it being extremely fast and then in here we have frameworks like um nox.js, 11t and swelter. um Nuxgs is basically the same. That next.js is for react.

A

Next is for view. 11T is a static site generator. um Also very interesting and people are very happy with it. um I think it makes sense to have a look at the down and out as well like what frameworks aren't particularly used, and they have a low satisfaction score, so people aren't happy with them either inside. Here we have hugo jekyll and angular, which are frameworks that gitlab pages documentation has regularly focused on.

A

So we might want to rethink and add more of the popular frameworks, especially from the up and coming area to there, so with a low satisfaction score, but still a huge adoption um in this area. We have jquery um express.js and gatsby, and I interpret this as okay.

A

We people don't like it, but they can't quite get away from from it, um and there's also a chart for minor frameworks, um which is basically just zooming into this little area, where we have a rather low adoption, but we can identify up-and-coming uh frameworks if they have a very high satisfaction score, and uh in here I think very notable is the rise of swelter kit, um which is.

A

Basically, a rendering engine for swelt apps.

A

In terms of backend technologies, um which is not that much a focus for many jam stack developers since they're, mostly front-end engineers, but in here we have a very interesting view, as what complements jam stack front ends on the back end, and we see that containers are a huge play. A huge role in this.

A

And micro services, obviously, but also functions as a service, uh takes on a huge role, and people are very happy with using these kinds of things. So um considering that gitlab has recently dropped serverless functions, I think this chart especially makes me want to reconsider whether we want to support something like that again.

A

What is the primary concern why people use the drumstack or how they develop jamstack applications and um not surprisingly, the number one concern is performance, and I guess this is something that gitlab pages has a little bit of catching up to do, um because performance is especially bad outside the united states. um The thing uh goes for uptime, um so people want a reliable service uh for jumps. Applications and security has increased since the last uh community survey. So previously devspeed was on on third place and and now security is increasing in importance.

A

um Then the jumpstart community survey quickly went into the demographic of the respondents, um which is also something I found rather interesting. um So there's a development as compared to last year's survey and we have a huge increase in younger developers.

A

The years of experiences are are just decreasing and most developers haven't have an experience of one to four years, um so we should consider jam stack engineers to be not particularly experienced. They. They, interestingly, relate that to their geographic region. The less experienced developers are more geographically diverse, so we get more developers from non-eu and u.s areas.

A

So what are the takeaways that I see in? In these stats one, um we should really should look at performance with gitlab pages, currently being used by mostly technical industries, um we're leaving a huge market of non-technical industries untapped.

A

um So there's a huge opportunity um and we should, as I said earlier, we should revisit serverless functions or edge computing um in that regard, um and we should think about jam stack sites as sites that serve between hundreds and thousands of users, mostly, and if we want to catch up on the enterprise market, we should also consider serving sites that have millions of users.

A

In terms of documentation, we've previously focused a lot on frameworks like hugo or jekyll or gatsby, um and they are becoming increasingly unpopular.

A

So we should revisit that kind of thing and if we focus on younger and less experienced users, we can strengthen our positions in non-us and eu markets.

A

If you want to read through the findings yourself, I've created an issue in the jam stack meter project and I've posted the link in the notes below I'm actually very interested in our own customers. Experiences and approaches so feel free to comment on the issue. If you have something to share, I like anecdotes.

A

That will be something very useful to me.

A

As I said, this was it for this week's update tune in next week for more, my plan is to go a little deeper on fastly deployments and uh also having a little play with netflix ems. At this stage- and I hope I'll see you then bye.