GitLab Incubation Engineering, 9 Jan 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Incubation Engineering Jamstack -- Weekly Demo January 9th 2022

Description

Update Issue: https://gitlab.com/gitlab-org/incubation-engineering/jamstack/meta/-/issues/17

All Weekly Updates: https://gitlab.com/gitlab-org/incubation-engineering/jamstack/meta/-/issues/5

A

Welcome back and happy new year to all who celebrate this last year was a fantastic one for gitlab. I hope the next one will be just as good. I want to take this opportunity to take a step back and now look at the big picture.

A

Let's talk about my vision for jam stack at gitlab and how I want to get there.

A

I think gitlab is the ideal platform for dance tech. It's already the one place where you're able to collaborate, deploy, maintain secure and monitor every part of an application, that's built on the drumstick architecture.

A

Now thinking of deployment platforms, there are already amazing solutions out there and that's great, but I do think there's a space for us. I like to think of gitlab as the linux of the deployment platforms. It's open. It's adaptable!

A

It's the one you use if you want to self host on site um now, follow me for a quick thought experiment if we think about jamstack applications, let's mentally reduce the concept to front-ends. For now, if we break down the concept of the scale of an application, there's an axis of pageviews going from a small scale, app with a couple of hundred to large-scale distributed applications with millions of patreons.

A

Now, let's add another access to this diagram concerning site complexity. This probably boils down to the number of pages or routes.

A

So now we'll end up with this 2d diagram of page use versus site complexity. Let's look at what kind of apps are in what space?

A

Now in the lower left corner, we have small, simple apps like product information sites, landing pages demo sites, then again, there's apps that can still be called simple, but they may have loads of pages like documentation, pages of popular frameworks or one-off campaign websites.

A

Now, let's add in the site, complexity access complex sites with not too many page views, I'm thinking about manuals, content repositories, our handbook, for example, but there's also the most difficult one sites with hundreds or thousands of individual pages and millions of page views, e-commerce, for example, or news websites.

A

Each of these apps would profit a lot from the jamstack architecture, but they have very distinct needs and I believe the architect's priorities are very different for each class.

A

I mean everyone cares for developer speed, but the focus will shift to availability and response time. The more pageviews an app has, conversely, on the x-axis, the more complex, an app gets, the more important the reduction of build times becomes.

A

I mean the traditional approach for complex apps is to not build a static site at all and just deliver it at runtime. That's the classic realm of cmss like wordpress. The big apps will also put some caching on top to solve the speed issue.

A

But now here's why I'm showing you all this? The innovation in the jamstack space has historically focused a whole lot on the left hand, side of this diagram, but gitlab is uniquely positioned to help users that want to innovate while working on the right hand, side and I think that's our niche.

A

I want to make working in the complex site space as seamless and, let's say fun as on the left, and I want to stretch this video update too long so I'll go into more detail in a later video, but I still want to talk on a high level about how I want to get there.

A

I try to order this by priority, but it is fluid.

A

One I want to improve the user experience around gitlab pages pages. Is such a well-made app there's been so much thought put into the code base and yet the front end is currently basic. It's hidden. The templates are old, it just doesn't look like it's getting a lot of love from us and, let's be honest, the ui is the first thing. The users make their judgment on whether or not to use the feature.

A

So in this area we're just cutting up to what netlify or versa have been doing for ages. So I don't expect this to generate a lot of buzz, but I do think it's utterly important to build trust two.

A

Once the catch-up phase has seen some progress, I intend to increase visibility by writing blog posts about how to on deploying to pages for each of the most popular front-end frameworks and a post each for using a cdn in front of pages with fastly and cloud flare and three, and this is where we start to tackle the right hand.

A

Side of the diagram that I've established earlier experiment with ssr support, server, side, rendering or distributed persistent, rendering, dpr or incremental static regeneration is especially important for the big complex sites and, I think, there's the most innovation opportunity.

A

However, especially when talking about dpr, the framework and deployment platform need to integrate closely together. That's why those solutions at the moment require a specific framework and platform combination like nexjs and versa.

A

As far as I know, there's no established protocol at this time.

A

My idea would be to pick out one frame, front-end ssr framework and figure out how to create an open protocol for deployment platform and framework to work together. I was eyeing swelter kit for this. I think it's an ultra promising framework still in an early stage of its evolution, but seeing how excited the community is about it. I think it may be an incredibly promising potential successor to next year four serverless functions.

A

I think it fits well into what gitlab does and it's incredibly useful for jamsac apps. I know we ditched our last attempt, so I want to see what went wrong and, if there's a chance to improve upon it,.

A

Last, this is a side track, so I don't know yet if when and how it fits into what I do. But it's an idea ahead. So here we go cms.

A

I think git lends itself extremely well not just for code but for static content, creation, collaboration and version, but it needs to be simplified. The noise needs to be reduced for non-developer personas, so there's a case to be made for a cms that, instead of a database, uses git as a backend.

A

There are a few solutions that do that. Netlify cms is maybe the most popular one, but it is a niche framework and you still need a separate build framework.

A

I was wondering if there's a space for a fully integrated working off the shelf solution, using our editor markdown capabilities for a back end and an integrated swelter kit for build that dpr thing works even better and maybe a button in gitlab to just click and deploy.

A

I mean, there's some overlap with the create stage, so that needs to be drafted out a lot more.

A

In any case, the understanding I have of incubation engineering is that there's a loose coupling of results and milestones. If I see an opportunity to create value, that's not linked to an area specific milestone. I will still pursue that path. For example, the pipeline editor. That only has little value that's specific to drumstick, but it's super useful for other parts of the organization.

A

Anyway, this was a quick look out into the jumpstack at gitlab future. I think I have my work cut out for me- probably six more people, but it's exciting, and I think we can create some incredible value for our customers to a successful gear thanks for watching and let's get to work.