Hello you guys, my name is Robert and today I'd like to talk to you about how my team and I are developing front end applications with real Kubernetes setups in the development stage and why we think that mocking APIs on the backend side is actually not that good of an idea. We'll be talking about the cloud native software development process and how we think it should be approached when it comes to developing front ends. But first let me introduce myself. I'm Robert. I'm a software engineer and co founder at Blue Shoe, a Munich based cloud native software development agency. And actually we started out with classic web development. However, around 2018 we shifted our architectural approach from building monolithic web applications to a more service oriented or microservice oriented software architectural approach. Somehow we landed at Kubernetes and we're really happy with that. Today we try to embed our learnings into tooling and processes we deliver for other developers to make their life easier and enable them to build great cloud native software. I'm mostly responsible for front end technologies. I do some project management and steer some of our open source efforts. In my spare time I'm a sourdough bread baker and a coffee nerd. I really like coffee. I also love to play the guitar. So in case you're interested in cloud native software development, or you're really into sourdough bread baking, hit me up on LinkedIn or Twitter, I'll definitely respond. So why do we actually need to talk about this? Typically when you're developing a distributed software architecture and the applications within it, there is some kind of back and forth communication. Typically this is done via APIs. And when you develop a front end there is an API or maybe a gateway on the back end which wraps all the APIs of the different services into one, and we somehow have to deal with that at the development stage. There are some approaches on how to cope with that. So basically you just can read documentation and develop your front end to the best of your knowledge. Latest in the CI CD process, you'll test whether things work or not. So this is not actually a solution. I just listed it here as you can do it this way, but probably no one does. Let's just scratch that from the list and come to the second point. You can mock the APIs on the backend side. So basically you create a static response for a certain request, a certain request body, a certain query parameter, and this is it. It's just statically returned from the mock server for the given request. Another way to approach this is just to set up a development backend. Basically you can spin up a VM or maybe a docker compose setup, or even a local cluster or remote cluster could do it just for your own, or there could be some kind of shared machine for different front end developers. This is another way to approach this at the development cycle, because when you're developers, the frontend, you somewhat want to talk to the API, fiddle around with responses, right? So what's actually the best way on how to approach this? Obviously when we started out, we basically did what everyone did at the time, which was mocking APIs. And this is actually fairly simple and pretty quick to do. There are lots of services, there are lots of tools and even some frameworks which have built in mocking capabilities which makes the whole thing really quick to set up and really simple actually. However, what we noticed over time is that there's quite some additional maintenance effort, right? Because you have to keep the actual response and the actual requests in sync with what your real code does. You have to ask yourself who is actually responsible over time on maintaining the mock service? Is it the frontend developers who is actually mocking with it all the time? Is it the backend developer who does the coding of the actual service of the actual API? Is it the testing team or quality assurance team? So this is not completely clear. I think in most cases maybe the back end developer. But yeah, you have to really make clear to your team who's responsible for that. And keeping things in sync, especially code, is pretty tough, right? So in case you're adapting a response in your code, in your application, you have also adapted in your mocking service, or maybe in the framework you're using, or maybe even the service provider you're using to provide the mock API. As a profit oriented company we're running, we also had to think about the costs. Are the costs worth the value of a mock API? I think this is pretty hard to answer, right? Because you could probably introduce some bugs in your mock API, you could probably go out of sync with the real code. And this basically leads to more and more errors within your development process and other teams. You have to dive in why things are not in sync anymore and what change or what response is actually the right one? Was the mocking API adapted beforehand or did just someone forget? These are basically events which result in additional costs and who's paying for it? Same thing as testing or documentation. This is additional effort. And I'm not saying that this is a bad thing, I'm just saying you have to be aware that there's additional costs and effort running into this part of the process. What I want you to take away is that mocking APIs is fairly simple, it's quick to set up, and still it's pretty hard to keep your code and your mocking service, the result of it in sync. Basically what we also believe is that there is more to a good mock than just a plain HTTP response or JSON response XML, you name it. So there may be some domain related problems. Just think about cross origin resource sharing, or maybe there are some timing issues or even some encryption SSL certificates you have to deal with which are different in the production system. What we did is we went back and looked at our software development process, or even in the context of cloud native software development, the cloud native software development process, there are quite some things involved. Of course, you have your code with your code style guide and you have a CI CD process. You have your documentation, the tests, monitoring, logging, you name it. There are lots of things involved when it comes to developing good cloud native software. What we basically establish for us is that the environments your software runs in, or the software is written in are a part of the software developers process. So you have your development, your integration, your production environments, maybe even some more called staging or testing environment. We are pretty much convinced, or basically we found out that this has a direct impact on how you write your software and the quality of it. So the environments really play a big role in your software development cycle. Let me first explain what we think about when we talk about an environment. So basically an environment is the space, the context, the setting which your software runs in. Over the past couple of years, there's been a trend of equalizing the environment your software runs in. And the strength was called containerization. And there are some quite popular technologies like Docker which do that for you. Basically what they enable you to do is federating your code in a very similar runtime on different machines. And this makes it more reproducible, right? You can expect the same results on your machine and your colleagues machine. However, there is more to a service presented architectural approach than just the runtime of your container, right? Your container may rely on some cache in the production system, some open authentication, there may be ns three storage, there may be some external services which are woven into your architecture. Suddenly you have a pretty different environment on your production side and your development side, right? Your development environment may look really different because maybe you don't have the external service available. You're mocking the code of your other containers. Maybe you don't use an s three. Instead you use a volume storage, I mean accessing files on s three and volume storage within kubernetes or docker basically works different. So the code has to work differently, right? This led us to think, okay, how can we minimize those differences between the environments we run our software in, so that we have something we call environment parity? And basically what we mean by environment parity is that the different stages our software runs in development integration, production look very very similar and also not only like the runtime built, also the orchestration of our services and even the services themselves. So these are basically the rough thoughts on why we think mocking just introduces or does introduce some additional problems to your development cycle you have to solve. And by using the real setup you're actually also using in production, you eliminate those problems. However, of course you have to think about how can I replicate my production environment on my local machine without being Kubernetes expert and front end developer in one person, right? Let me tell you about how we approach this. We think mocking APIs comes at a cost and in the long term it's hard to say if it's worth it or not. We're not really convinced, let's put it that way. Just be clear who is responsible for maintaining the mock of the API in the long term. And we'd really recommend put in some effort to make sure the mocking matches your stack. So just picking the first service provider that comes to mind or Google spits out probably is not the best thing to do here. So we try to maximize the parity between the different environments our software runs in and we try to minimize the differences. Basically what we do is in our development lifecycle we use a real Kubernetes setup for our developers. We are pretty much convinced that our DevOps people are super awesome guys and they put in so much effort in writing the Kubernetes description files like the Kubernetes manifest or maybe helm charts or customize. Why not make use of this really great result they created for our other developers for their development setups? So there are some solutions, I just put in some logos here, there's K 3D, there's minicube. Unicube is something we use and we built. So disclaimer, we are the creators of Unicube. Basically it's a pretty thin layer around K 3D which takes care of setting up a replica of your production environment on your local machine. So I guess it's demo time and I'll show you on how our development cycle looks like for our front end developers. But first, let me explain you how the architecture of our platform basically looks like. We have a Kubernetes cluster which does look the same during development and production. The only differences are the actual secrets which are used for development and production. So we have some security concerns there and splitting those up. And in front of all, we have of course, the frontend which talks to a gateway which is connected to Keycloak. Keycloak is an open identity provider which handles authentication and authorization for us. Basically it works with JSON web tokens. If you pass authentication, your request is forwarded to Apollo. Apollo is a pretty cool thing. It federates all our backend graphql interfaces, the public interfaces into one big graphql. This basically enables the front end developer to run queries across different services within one request. So if I want to have, maybe I want to retrieve all projects for a given organization and include the organization name and the project names, et cetera, in one request. This is totally possible and pretty easy to write. Let's head over to how we basically work with our Unicube setup. We have a platform which basically takes care of rendering the Kubernetes resources. I log in and after I logged in, there are some projects we have here the Uniq platform. There are all deployments listed within the platform. This is something our developers team set up for us. What they also did is they told the platform on how to render the charts, which values. These are basically hand charts, what values to use and how to resolve the secrets for the development charts. That's basically what they just put into the platform. And now I can use the unicube CLI just to set up a cluster on my machine to basically create my development environment. All right, let's head over to the CLI. First thing I need to do is to authenticate so that the platform knows I'm really allowed to access the helm charts, or actually the Kubernetes manifest, which is generated by the platform. And the CLI opens tab in the browser where I can authenticate. As soon as this is done, I just can spin up the project I just showed you in the web UI. And this looks pretty similar to docker compose. So what this command does, it creates a new cluster with k machine, or spins up an existing one, so I can actually manage multiple clusters on my machine. This one is already running and already also provisioned with the helm charts. So no need to wait for this here. Let's have a look at which resources or domains the cluster exposes for my local machine. So we just had a look before on the deck, on the platform deck. So running this command actually shows us which paths are available. So there are quite a few exposed here. We have the front end and we have the gateway, our authentication service key cloak. All right, so let's have a look at it in the browser. Basically what I'm doing now is accessing the link, the ingress command exposed to me as a user. What happened here actually is my authentication is tested by the keycloak service and the front end is executed from the front end deployment. And we access the real graphql interface which runs within the cluster on my machine. What we also can do is have a look at the GraphQl interface which is also exposed by the cluster. Let's have a look at that. And I can basically run my graphQl queries as they would run in the production system, my cluster and get the results here. Can have a look at the results, how they look like, can have a look at the documentation. GraphQL is self documenting how the schema looks like. And basically I also can execute mutations which really change things within the cluster. This is pretty cool. Now I can spin up my webpack development server and just work with the API. All right. This is basically it how we work at blue shoe when it comes to develop frontends KS applications with Kubernetes setup. I have to admit it was a bit slow running obs and running the full cluster on my machine, but basically it's a bit faster and working when I run it without recording a session. It was really fun to show you guys how we work, how our development flow looks like. Have a look at all the awesome projects like mini Cube, like K 3D. Also have a look at our project unicube. It's completely open source and really makes things easier to collaborate between DevOps back end developers and front end developers. So if you're interested in this, just hit me up, drop me a message on LinkedIn or Twitter. I'll be glad to help you. And well, mocking APIs is as I told you before, it's pretty simple and it's quick to set up. But what we found that this flow flows more, this development flow is better for us. It may be better for you or not. You have to find out if you have any critics or any additional information you need, just let me know. Really glad to be here and hope to hear from you guys. See you soon.