Multiple entrypoints

I think most Vite users have a single page that forms the basis of their application - a SPA or single page app. React Router or something will handle different paths, but it’ll all start from one index.html. Not us, however.

We render our index.html equivalent on the server-side (using Javalin with Pebble templates) so we can server-side inject some variables for our React code. We also have a bunch of different pages that serve as individual React pages. This means we might have a template like this:

{% block head %}
    {% include 'web/react.html.twig' %}
{% endblock %}

{% block body %}
<div>
    <script>
        const username = "{{ username }}";
    </script>
	<div id='user-root'></div>
	<script src="/dist/user-bundle.js"></script>
</div>
{% endblock %}

So, our Webpack config takes a bunch of entrypoints like src/user.tsx and outputs dist/user-bundle.js. Vite supports this but it took me a lot longer than I thought to figure it out. Documentation around this area expects you to be building a library with multiple entrypoints, which will get you code that won’t easily run in a browser. The Vite config is actually pretty simple:

export default defineConfig({
    plugins: [react()],
    build: {
        manifest: true, // crucial for our backend integration
        rollupOptions: {
            input: {
                user: 'src/user.tsx',
                foo: 'src/foo.tsx', //etc
            }
        }
    }
})

While Webpack would output a single bundled JS file, which somehow included CSS as well, Vite outputs dozens of JS and CSS files. Pointing our backend to it is easy in dev mode, after running vite:

{% block head %}
    <script type="module">
        import RefreshRuntime from 'http://localhost:5173/@react-refresh'
        RefreshRuntime.injectIntoGlobalHook(window)
        window.$RefreshReg$ = () => {}
        window.$RefreshSig$ = () => (type) => type
        window.__vite_plugin_react_preamble_installed__ = true
    </script>
    <script type="module" src="http://localhost:5173/@vite/client"></script>
{% endblock %}

{% block body %}
<div>
    <script>
        const username = "{{ username }}";
    </script>
	<div id='user-root'></div>
	<script src="http://localhost:4568/src/user.tsx"></script>
</div>
{% endblock %}

We no longer include react.html.twig - previously we had shared react.js and react-dom.js between all our entrypoints, handling the code splitting ourselves. But Vite does all that for us.

Instead we inject a bit of custom code which handles hot-reloading for us (that’s something we didn’t have before!). And where before we pointed to our bundled js file, now we point straight to the .tsx file. This is an unexpected bit of magic but from here Vite’s dev server will provide the compiled JS, CSS, and whatever other resources we need.

Building for production

Getting production working, on the other hand, was a fair bit more complicated. For any given entrypoint, like src/users.tsx, we get a bunch of files like dist/users-abc123.js, dist/users-foo456.css, and dist/users-789def.js. To know which ones we need to import, we read the dist/manifest.json file, which contains a key/value mapping of every dependency for every file. Look up src/users.tsx and you’ll get something like this:

{
    "src/users.tsx": {
        "file": "/dist/users-abc123.js",
        "imports": [ "/dist/users-789def.js" ],
        "css": [ "/assets/users-foo456.css" ]
    }
}

The file is the entrypoint to our app, which will import our other dependencies. But css contains only the CSS files necessary for this JS file - important to note that we need to recursively add the CSS files for all the imports to ensure we get all the CSS needed. Then our template will look like this:

<script src="/dist/{{ manifest.file() }" type="module"></script>
{% for css in manifest.css() %}
    <link rel="stylesheet" href="/assets/{{ css }}">
{% endfor %}

So! If we’ve done our recursion right we should end up with a rendered HTML file linking the entry point JS and all the CSS files we’ll need.

React error #130 in prod

Once you have your production build going, you might discover something unexpected: crashes that did not appear in the dev build. To be honest I’m a bit shocked that this is an open issue since early 2021 - discovering a bug only when you hit prod seems like a big deal! Apparently it is caused by an older-style export syntax that is not supported by Vite. Tracking down the library, on the other hand, is non-trivial: I did it by commenting out significant chunks of code bit by bit until I’d found the culprit. Once I’d found it (react-modal was the cause) the fix is relatively easy. Change this code:

import * as ReactModal from 'react-modal/lib';

To this:

import * as RM from 'react-modal/lib';
const ReactModal = (RM as any).default || RM;

An easy fix… but can be a little painful to find.

Circular references breaking createContext

Fixing this one was easier than I thought, thankfully. If you have a file like this, with a React context:

export const Context = React.createContext(null);

export default function () {
    return <Context.Provider value={42}>
        <Child/>
    </Context.Provider>;
}

And elsewhere you have a child.tsx that references this context:

export function Child() {
    const value = useContext(Context);
}

You have a circular reference: the first includes child.tsx, while child.tsx imports Context from its parent. Apparently this is no big deal for Webpack but Vite can’t handle it - something to do with hot module reloading, so at least this error only happens in dev.

The Github bug has some helpful tips. Here’s how I fixed it:

1. npx madge src/index.tsx --circular to find the circular references
2. This listed entries like src/index.tsx > Child.tsx
3. From here I discovered the circular reference above
4. I moved the Context into its own file, src/context.tsx, and imported it from both index.tsx and child.tsx

import { Foo } → import type { Foo }

Typescript 3.8 added Type-Only Imports which I hadn’t heard of before this migration. They reduce a little bit of ambiguity when calling import { Foo } - is Foo something in Javascript (e.g. a class) or is a type (i.e. something that will disappear in the compiled JS)? To reduce ambiguity, you can use import type { Foo }.

This option is not an option in Vite - it’s a requirement.

Luckily, there are a couple ways to make this fix easy. There’s an eslint plugin to enforce this, and you can immediately apply it to your whole codebase. And if you use a Jetbrains IDE like IntelliJ, it’ll use the import type syntax if your tsconfig.json has importsNotUsedAsValues: 'error'.

Typechecking

Like other modern “blazingly-fast” build tools, Vite does not attempt to typecheck your code, instead suggesting you rely on your IDE for it. There are some plugins to help though. I used vite-plugin-tsc-watch which only had one small hiccup - without noEmit: true in your tsconfig.json you’ll end up with transpiled .js files throughout your codebase.

Some dependencies will break

We used an old notification library called Noty. I was unable to get this to work with Vite at all. Turns out the library is no longer maintained and there are plenty of replacements so it wasn’t a big deal. Bowser was another one that I replaced with detect-browser.

My favourite calendar library, FullCalendar, needs its imports to be in a particular order which Vite seems to ignore. Luckily FullCalendar have a new release out to fix the issue.

Conclusion

There have been a couple other small issues - CSS imports sometimes seem to be in a slightly different order to Webpack (but again, only in prod, not dev). HMR in certain cases causes UI elements to disappear. But the instant updates on editing is so fast that it’s easily worth it - plus shaving a couple minutes of our build time is a nice bonus.

On the other hand, I’m surprised at just how much work it takes to use what the community seems to have settled on as the future of build tooling in the ecosystem. With the restrictions and caveats I ran into, it feels like I must be on the bleeding edge. I (naively) expected that Vite would be just plain better, and while I’m still happy with it there are more drawbacks than I expected.

Want to skip the explanation and just check out the code? Here you go.

The old way: Building a bridge from both ends

Our websocket client code would send messages to our backend, which would handle the message and forward it on, hopefully to the right destination.

In reality, keeping track of what messages contained what fields, where they were supposed to go, and who was allowed access got messy pretty quickly.

The new way: A clearly defined interface(s)

Let’s group our messages in two:

• Messages sent from the client
• Messages sent from the server

This separation gives us a hint on how we can separate our calls in code in terms of how we handle it. So we build two interfaces for our WebSocket service, one for each category:

• ChatApi, with methods like sendMessage() for when a client initiates an action
• ChatEvents, with methods like onSendMessage() for when a client receives an action from the server

These two can be combined into a single TypeScript file for clients to use. The server side is a little more complicated; here’s how I did it:

1. Bind all methods from ChatApi to an implementation, and redirect websocket messages to this implementation
2. Create a proxy object that implements ChatEvents, redirecting any calls to it to a list of WebSocket sessions that have registered for that event
3. Add a special extra “register” method to our WebSocket connection, that allows clients to add themselves to the list of sessions in the client.

The result is client code that looks like this:

const api = new ChatApi({onOpen: () => console.log("connected")})
api.onMessage(msg => setMessages([...messages, msg]))
//...
api.sendMessage("Wow, that was easy!")

With our TypeScript file clearly defining how to interact with our backend, a little bit of reflective Kotlin code connecting our WebSocket connection to our backend implementation, and typescript-generator to share types, we couldn’t have a safer, easier to use API.

Who listens to what?

Not every message should go to every client. For example, in a chat app, private messages should only go to their destination. I handled this with a special annotation on method parameters that allow filtering of destinations:

interface ChatEvents {
    // listening to the "onMessage" event will get all group message events
    fun onMessage(message: String, from: String)
    // In this case, you'll listen for "onPrivateMessage/<username>" events
    // to ensure you only receive messages meant for you
    fun onPrivateMessage(@Filter to: String, message: String, from: String)
}

By default messages are sent to every listener - but perhaps you might want to filter messages from being sent back to the caller? I haven’t done so but depending on your use case this might be worth considering.

Show me the code!

I’ve uploaded a simple demonstration on Github if you’d like to dig into the details on how it works.

• Java interfaces describe each API and its endpoints
• Each interface is connected to its backend implementation with a special Javalin handler which exposes each endpoint via HTTP, parses arguments, then calls the implementation
• Some custom tooling loops through every interface and generates a Typescript class for each one, with methods to call each endpoint
• The Java library typescript-generator generates Typescript definitions for all the classes used in arguments and return values of the APIs

The end result is that as we add endpoints to our backend, our API client automatically generates the methods to call it, making frontend-to-backend calls almost as easy as native calls. Read on for details on how it works, or view the demonstration on Github.

API definitions

This is the easy part. Our API interfaces look something like this:

interface UserApi {
    UserDto getUser(int userId);
}

Backend implementation for our API

Javalin is a great webserver that provides exactly the balance of power-to-simplicity that we need. A backend call might look something like this:

POST /api/UsersApi/getUser
{
    'userId': 1001
}

So, we create a handler for each of these calls. It involves a bit of reflection which is a bit hairy but makes things easier for devs:

public static void main(){
    var app = Javalin.create();
    // UsersApi is the interface that defines the endpoints.
    // UsersService is the backend implementation of UsersApi.
    // We repeat the below for every API we want to expose.
    expose(app,UsersApi.class, new UsersService())
    app.start()
}

private <T> void expose(Javalin app, Class<T> api, T implementation) {
    String apiName = api.getSimpleName();
    for (Method method : api.getMethods()) {
        // handle calls to, for example, POST /api/UsersAPI/getUser
        app.post("/api/" + apiName + "/" + method.getName(), (ctx) -> {
            Map<String, String> body = ctx.bodyAsClass(Map.class);
            List<Object> args = new ArrayList<>();
            for (Parameter param : method.getParameters()) {
                String json = body.get(param.getName());
                var arg = GSON.fromJson(json, param.getParameterizedType());
                args.add(arg);
            }
            try {
                Object result = method.invoke(implementation, args.toArray());
                String json = objectMapper.writeValueAsBytes(result);
                ctx.result(json);
            } catch (Exception e) {
                throw new RuntimeException("Failed to invoke " + apiName + "/" + method, e);
            }
        });
    }
}

That’s pretty much it. For every API, then every method, expose an endpoint that deserializes the arguments given, then calls the actual implementation’s method with those arguments.

The only special thing I’d note here is that the body of our request is not a single object we can deserialize immediately, but instead is better thought of as a key-value pair of parameter names to a JSON string. So it’s essentially doubly-serialized JSON.

So! Our backend is ready to receive requests. Next up is the API client.

Typescript client

The code here works a little like the above again - given an interface like UsersAPI, iterate over its methods, and iterate over its arguments. However, along the way, we build a string by appending bits of Typescript to it. The code here is a bit ugly so I’m going to write some pseudocode to describe it:

String toTypescript(Class... api) {
    for each api:
        typescript += "class ${api.getSimpleName()} {"
        for each method:
            typescript += "${method.getName()}("
            for each parameter:
                typescript += "${parameter.getName()}: ${getType(parameter)}, "
            typescript += "): Promise<${getType(method.returnType)}">
            var body = Map<String, String>
            typescript += "return fetch('/api/${api}/${method}', {"
            typescript += "   method: 'POST',"
            typescript += "   headers: {'Content-Type': 'application/json', 'Accept': 'application/json'},"
            typescript += "   body: JSON.stringify({"
            for each parameter:
                typescript += "${parameter.getName()}: JSON.stringify(${parameter.getName}), 
            typescript += "   }"
            typescript += "}).then(res => res.json())
        typescript += "}"
    return typescript
}

Hmm… is that more readable? If you’d prefer you can read the actual code instead. Mine uses raw strings for simplicity, though I suggest using a templating engine instead. Here’s what you might expect to see in the generated Typescript, as an example:

class UsersAPI {
    getUser(userId: number): UserDto {
        return fetch('/api/UsersApi/getUser', {
            method: 'POST',
            headers: {'Content-Type': 'application/json', 'Accept': 'application/json'},
            body: JSON.stringify({userId: JSON.stringify(userId)})
        }).then(res => res.json())
    }
}

We store the above file in target/ts/api.ts, and generate this file using the Exec Maven Plugin which lets us run the client generator when we run mvn package.

One bit of magic I’m skipping over is the getType(parameter) call. This converts Java classes to Typescript equivalents. Here’s basically how the conversions work:

• String -> string
• int, Integer, float, Float, double, Double, long, Long -> number
• Object -> any
• Array<T>, List<T>, Set<T>, Collection<T> -> Array<T>
• Map<K, V> -> Record<K, V>
• Otherwise, just use the object’s class name (e.g. UserDto)

Now you’re almost ready to call new UsersApi().getUser(1001) - we’re just missing the Typescript type for the UserDto returned.

Typescript definitions for our Java types

This one’s pretty easy. We have a Java package that contains all the types that we want to use on the frontend (com.company.dtos), and we point the Maven plugin typescript-generator to it:

<plugin>
    <groupId>cz.habarta.typescript-generator</groupId>
    <artifactId>typescript-generator-maven-plugin</artifactId>
    <version>2.32.889</version>
    <executions>
        <execution>
            <id>generate</id>
            <goals>
                <goal>generate</goal>
            </goals>
            <phase>compile</phase>
        </execution>
    </executions>
    <configuration>
        <classPatterns>
            <classPattern>com.company.dto.**</classPattern>
        </classPatterns>
        <outputFile>target/ts/types.ts</outputFile>
    </configuration>
</plugin>

Assuming we have a UserDto class like this:

public record UserDto(int userId, String username) {}

We’ll end up with a types.ts file like this:

interface UserDto {
    userId: number,
    username: string
}

Putting it all together

So, now we have:

• A Javalin server with endpoints ready to deserialize parameters for each of our backend methods
• An api.ts file with classes ready to query each of those endpoints
• A types.ts file that describes the types for both the parameters and returns of those endpoints

The end result is that adding a new endpoint looks like this:

1. Add void changeUsername(int userId, String newUsername) call to interface, and implement it on the backend
2. Run mvn package to update our Typescript files
3. In the frontend, write new UsersService().changeUsername(1001, "foo") - that’s it!

Caveats

There are a few lessons we’ve learned along the way that are worth noting, including:

• Java’s Map is a lot more flexible than Javascript objects. Particularly in Javascript objects can only have strings as keys, so don’t return a Map<MyRecord, String>
• Javascript has no method overloading so if you declare a getUser() and getUser(int userId) you’ll run into issues.

Conclusions

I’m a big fan of typed languages (hence Java backend and Typescript frontend) but traditionally there is a disconnect between types on the two domains. This tooling allows us to modify a method or class in one place and immediately be comfortable using it everywhere else, or see errors during compile time when we’re misusing it. This tooling catches so many bugs and allows development to be so much faster that I can’t imagine working without it now. I know there are some similar tools out there but they either add a significant amount of complexity (OpenAPI) or are locked into a certain stack (Remix). Building our own offers significant control at a relatively minor cost (i.e. it’s just not that complicated).

As an example: we pass dates around to the frontend with epoch millis. But sometimes when you’re staring at a long you might think it stores epoch seconds. Java has a better class for this: Instant, which you can retrieve either from. I wanted our devs to use Instants instead of longs in our DTOs, so:

1. I added a long to Instant deserializer and Instant to long serializer to our JSON serializer
2. I told typescript-generator to convert Instants to numbers with a <customTypeMapping> in types.d.ts
3. I adjusted my getType(parameter) class to convert Instants to numbers instead in api.ts

That was it! Having written our own tooling this was an easy task and allowed us to further strengthen our use of types to reduce another source of bugs.

Complete demo

You can find a full demo on Github here: crummy/java-typescript-api-generator

1. Docker Compose runs
2. The old web app is taken down
3. The new web app is started

Between steps 2 and 3, users will see error messages on our website (for a few seconds). Not long but long enough that we’d avoid deploys during busy times, and I wanted our developers to be able to deploy as often and as easily as possible.

Seamlessly deploying the app

The engineering team at Tines came up with a solution which I have adopted. The process involves, with a simple bash script:

1. Spin up a new instance of the web app using Docker Compose
2. Wait until it has booted
3. Reload Nginx
4. Stop the old instance of the web app
5. Reload Nginx

This is what more complex systems do during deployments but the simplicity of a bash script and Compose is pretty nice.

Seamlessly handling WebSocket clients

Even if the above ensures no HTTP requests are dropped, any live websocket connections will be interrupted. There’s a simple solution for that:

1. Register a shutdown hook in the web app: on disconnect, send a special “RECONNECT” message to all WebSocket clients
2. Clients, upon receipt of the message, disconnect their WebSocket connections, pause a moment, then try to reconnect
3. Their new connection is handled by the new web app instance

Reducing complexity with Caddy

I was proud of the above work, but it did bug me a bit. We had made our deployments seamless enough that we could deploy without anyone noticing, but our simple “docker-compose up -d” script had been replaced with something fairly esoteric, even if it was plain Bash.

An unrelated problem had lead me towards thinking of replacing Nginx with Caddy, a new-on-the-block webserver that is a lot simpler to operate. I wasn’t sure how it would work with the seamless deployment script we’d created, so I dug in to see how hard it would be to replicate and discovered a simple difference between Caddy and Nginx:

• With Nginx, if a request comes in and a backend is not available to handle it, an error is returned to the client immediately
• With Caddy, if a request comes in and a backend is not available to handle it, Caddy waits for a while for the backend, giving up only after a timeout is reached.

This change in behaviour means that we are able to achieve near-seamless deployments - if you happen to visit our website at the wrong time, you might experience a brief delay (probably not noticeable due to caching) but you won’t see any ugly error messages.

Simplicity wins

So, with Caddy instead of Nginx, we can throw away the ugly bash script and go back to plain Docker Compose deploys. As long as our web app boots up quickly, it’s difficult to notice a deploy happening even if you’re watching closely.

Sacrificing a small amount of functionality for a big decrease in systemic complexity is a definite win in my opinion.

You can find a full working demonstration of the Nginx solution on Github.

Maybe avoid Docker

You can try Jetbrains Projector out right now with their Docker setup: https://github.com/JetBrains/projector-docker

However, beyond clicking around and marvelling at how much like local IntelliJ it is, you’ll quickly run into some limitations: you’ve got to mount your user folder for persistence (easy enough), the Docker container is missing permissions and tools you’ll soon want to install (possible to fix) and once you want to run a service and expose a port… it all gets a bit hairy.

Don’t get me wrong: I love Docker. But if you want to use Projector heavily I suggest skipping it here.

Step one: Install Jetbrains Projector

I’ll assume you have WSL2 installed. To install, pull the Projector repo and follow their install steps. I’m on Ubuntu, so I ran:

git pull https://github.com/JetBrains/projector-installer
sudo apt install python3 python3-pip 
pip3 install projector-installer --user 

You might need to restart your session if you have a fresh WSL2 install - the installer would have created a ~/local/bin folder and your PATH won’t have noticed it.

projector run will let you confirm it’s working, though you’ll only be able to access this from your Windows machine.

Step two: Expose WSL2 ports to the local network

There are a variety of ways of doing this, but as far as I can tell, this is the easiest and most reliable.

WSL2 does automatically expose ports from the Linux environment to your local machine so you can access them in Windows - but only your local machine, so you can’t access them from your laptop on the same network. There’s a tool that modifies this behaviour so the ports are exposed to all listeners, called WSLHostPatcher:

1. Download the latest release from https://github.com/CzBiX/WSLHostPatcher/releases (I tested v0.1.0)
2. Unzip the file
3. Run the WSLHostPatcher.exe

Now you can run projector run in WSL2 and access http://windows-computer-name:9999 from any machine on your network.

Step three (optional): Set up SSL

Browsers lock some functionality behind SSL connections only - for example, if you don’t have HTTPS, then copy and paste might not work super reliable. The easiest way to fix this is with Caddy.

First, install Caddy on your WSL2 instance: https://caddyserver.com/docs/install#debian-ubuntu-raspbian . Then, create a Caddyfile like so:

localhost {
        reverse_proxy localhost:9999
}
<windows-computer-name> {
        tls internal
        reverse_proxy localhost:9999
}

Now you can curl https://localhost from within WSL2 - but notice if you access https://localhost you get SSL errors. That’s because Caddy generates its own SSL root certificate, and though it automatically trusts them on the machine you have Caddy on (WSL2), we have to manually trust them elsewhere.

Find the root certificate in Caddy’s data directory, and copy it to your laptop (either via SCP, or copy+paste). Then add it to your local keystore (on a Mac, by double clicking it, then opening Keychain Access, searching for Caddy, then marking it as Trusted.)

Now you can visit https://windows-computer-name from your laptop while IntelliJ runs on your desktop. Enjoy!

My goals were:

• As cheap as possible to run - margins are pretty thin on the orchard and you can only sell during the season so we don’t want regular monthly fees. Plus any small cost and you start running into Squarespace territory.
• As simple as possible to use - for customers, this is a page where they can choose what they want and buy it, no fancy marketing or gloss.
• Flexible enough for other stores - there’s a local grocery store that’s doing delivery during COVID-19 and ordering is a painful process with a PDF to print. It made me think there must be other small shops out there with a need for this.

Here’s what I built, and how:

AWS

Amazon has a bunch of tech to host a website, and to hook you they have a free tier on a bunch of their services. I used AWS Lambda for my backend, S3 and CloudFront to host the frontend, and DynamoDB to store shop configuration and order data - all of which should be free, unless I get some extremely unusual load. The only AWS service that’s not totally free is SES to send notification emails to the store owner when a purchase has been made - and that’s 14c/GB, which is a looot of emails.

I used Serverless Framework to deploy most of this stuff, though the static website is deployed separately, set up with CloudFormation. Initially I felt a little iffy about adding a layer of abstraction but Serverless has a lot of useful plugins and frankly writing CloudFormation is a real pain.

Stripe

Stripe will let you integrate as much as you want with them - hooking deeply into their APIs to handle payments and handling everything else on your end. But they also have something called Stripe Checkout which lets you push as much onto them as possible. My backend gives Stripe a list of items and a price, then I redirect the customer to Stripe which collects shipping address, email, and payment. When the charge has been successfull, Stripe notifies the backend (with the payment and address details) and the customer is redirected back to an order completion page I made. Super easy.

They also have a really nice test data toggle with separate API keys. Testing third party integrations is often a painful experience and this really made it easy.

Google Sheets

Almost the highlight of this project is the use of a single Google Sheet as a CMS.

Crucially, this allows clients to easily manage inventory in an interface they’re already familiar with, and saves me not only from building a UI and backend to manage all this but more importantly removes the need for an admin login which saves us from a whole set of problems. Much easier to use the Google Sheet’s permission system to manage things.

The API is a liiittle slow to respond but it’s a small issue and it would be easy to cache the spreadsheet in DynamoDB if needed. (Actually, if I really wanted to do this right, when the spreadsheet updated I’d trigger a Lambda to generate a static page generated from the spreadsheet…)

What went wrong

The backend is built in NodeJS, but it didn’t actually start that way. I built the entire thing in Kotlin using the Ktor web framework, planning to run it in Fargate, an AWS service that hosts Docker containers - but it turns out Fargate doesn’t have a free plan. AWS Lambda looked nice but as much as I love Kotlin, it runs on the JVM which runs very fast but takes an unusually long time to boot up.

How Lambda works is when an HTTP request comes in from a user, it boots up the service to respond to it, handles the request, and then shuts down the service later - everything is done on the fly. This comes with a lot of advantages but it does mean that if your service takes a while to boot, users will suffer slow response times.

So, I threw out all my Kotlin code and rewrote it in NodeJS, known for fast boot times. I went with Typescript which was a pleasant experience, particularly when querying the Google Sheets API.

Conclusions

• For someone who isn’t a frontend developer, Svelte was a pleasure to work with. I understand its advantages are being responsive and small but I appreciated being able to write actual HTML+CSS+JS and it all working like I expected.
• Google Sheets as a CMS is a highly underrated option! Reading and writing to it is easy and it’s so good not to have to deal with security on your own app. Obviously you wouldn’t want to use it for something huge but there are lots of small sites out there.
• Writing CloudFormation reminds me of the worst parts of programming: googling for a solution, copy pasting code, hoping it works. I can’t imagine ever writing it from scratch and I can see why abstractions like Serverless Framework are popular.

Starting is tricky - I lie on my back with my board downwind and the kite directly above me, then swoop it downwind to provide enough power to pull me up on top of the board. This is the easy part though. Now the kite needs to be put in the right position to pull me along at the right speed, the board needs to be in the right place to go where I’m headed, and I need to lean back the right amount to counter- balance the whole thing. I can’t figure out what the combination of all three things are, but sometimes I hit upon it by accident and then I’m off.

It is very wind-sensitive however (obviously I suppose). 15-20 knots is the sweet spot (for me at least) and I’ve become very sensitive to the inaccuracies of the weather report.

• I said it last week but Apex Legends is still very good. I have a few more wins under my belt now but losing doesn’t make me feel that discouraged. I think there is a balance to be struck between making player deaths important and not causing frustration.
• I was reminded of the one-hand-one-bounce rule in kids cricket (usually a rule adopted in casual games where a tennis ball is used - the usual rule is that catching someone without a bounce gets them out, but this rule allows a single bounce if you catch it with a single hand). I think this was the first time I thought about game mechanics and balancing, and it’s still a great example of it.
• We bought a car. Figured we would need one eventually so may as well get it now than keep spending the odd money on taxis or rentals.

Though Apex Legends does introduce some genuinely new concepts, they’re mostly small improvements to the core gameplay loop, or the streamlining of existing systems. A few things to call out:

• Even after being killed, your teammates can rescue your “banner” and take it to special respawn points that bring you back - without any gear, however. This avoids unlucky players having to spectate the rest of the match, but doesn’t unbalance things too much as the time and equipment loss your team suffers can be a significant setback.
• The map plays a lot more vertically than other battle royale titles. Part of this is just level design, but the lack of fall damage and ziplines that take you way up and let you semi-respawn again help too.
• The loot UX is just plain easier - picking up weapon attachments and they automatically equip, you can’t easily pick up an item you don’t need or an item that is a strict downgrade, and overall less time is wasted fiddling with inventory.
• Communication is easy and automatic thanks to a smart spotting system that lets you easily point out helpful information or warnings to your teammates plus your characters chatting useful information out loud at times.
• The game just “feels” good. This partially comes down to low input lag and consistent frame rates but I think you really can see the studio’s FPS experience coming through strong here.

I think I conceptually appreciate games that push boundaries a bit more, but while the back-of-the-box description of Apex Legends sounds boring, actually playing it feels instantly satisfying on a gut level. Respawn Entertainment gets first person shooters.

Someone once told me that all code is baggage and I wish we remembered this more often. Spring Boot lets you do tasks that may have been complicated otherwise very easily, but it comes with a lot of code AKA baggage, and it will weigh you down. One obvious but painful side effect of using a complex framework is large and inscrutable stacktraces. Developers spend a lot of time looking at stacktraces, and making this task harder is not to be taken lightly!

In a more abstract sense I think as developers we should at all times try to limit complexity. But not just complexity of the code we write - libraries, frameworks, etc all increase complexity of the application as a whole. Writing a hundred more lines (or even a thousand) could easily be worth it if you can avoid tying your application to some larger monster framework.

• In my case I’ve been working on an application that uses Spring Integration, which seems to be a message bus on top of Spring. Methods have inbound and outbound channels, and this dictates the program flow instead of methods just calling other methods. I’m trying to guess at why it was used and my only guess is: it seems cool. But it adds nothing else but complexity!
• Third lesson of kitesurfing and it’s hard to stay patient. I just want to fly the kite around in a good wind, to feel the power of it! Next one will be a private lesson so at least I don’t have to trade off so much.
• I enjoyed https://www.youtube.com/watch?v=rE3j_RHkqJc&fbclid=IwAR3vMzXWVVNQJRYW4YejiSw3OQJYEPDYymiTWxa0tyZCPLUezqkDeaki6W8. Reminds me of Snow Crash. One of the ideas I’ve been coming to terms with over the last year is that allowing people to communicate faster and easier than before can not only have negative effects but is perhaps a net negative overall? I hope Mark Zuckerberg stays up at night thinking about this.

• Watched The Breaker-Upperers, which was very funny though the drama seemed a little forced.
• Trying to get our finances in order, I set up Firefly III, a self-hosted finance manager. Seems to work pretty well so far, there’s a way to access most banks via a shared API called Spectre. The whole point is to be able to answer questions about our money (e.g. how much do we spend on X) but coming up with a categorization/tagging system is difficult when you don’t really know what questions you’ll want to ask in the future. There are similar problems in software architecture.
• Don’t know what my superpower is but my inability to remember names is definitely my superweakness.