Start with a page that reads from a database. The SQL generator produces Go methods returning records. The page's Go uses those records, and the template reads their fields. While I'm editing, the interpreter needs to run that changing Go too. I need the whole route to work before I can see my page.
GoSSR started as the server-side rendering tool. Alongside it, I've been building the querying tools, the interpreter and shared services for client applications. They keep meeting in the applications. Giving them a home together is starting to make more sense than keeping the projects apart.
I'm calling it Piko. GoSSR describes one job, and the project is getting harder to describe that way.
Bringing them together gives me somewhere to change a shared part and follow its use into the application, instead of carrying that change between projects first. The storage tools and other services belong here for the same reason. I keep needing them in what I build.
I'd like the development speed I associate with Node.js. Change something, save it, see the result. The interpreter is my way of working towards that for the Go in a page. Deployment should give me the Go code and assets together in a compact compiled application.
The ordinary application parts should come with it. Adding uploads or querying some data shouldn't start with choosing another collection of packages and learning how to connect them, because I've already got tools for those jobs. Connecting them again is time I could spend on the application.
The JavaScript supply chain puts me off assembling more dependency trees to trust and maintain, Piko uses libraries underneath its interfaces but I can choose and connect those once for the framework. Even the docs use Docusaurus, with its Node dependencies. I'm quite happy to let it have that job.
Giving it a name makes it feel alarmingly official. A collection of folders can stay a collection of folders for ages. Give it a name and suddenly I'm tempted to think about a logo, which is a very appealing way to avoid finishing the code.
I could be choosing colours and typefaces and.... yeah, you get the picture.
The parts need to agree
I hate the compatibility minefield around frameworks, a plugin wants one version, an adapter wants another, and suddenly I'm reading release notes for half the project before I can add a single feature to the application I'm trying to build. Handing that job to every user would spoil the point. The database page gives me an integration test to build. I can run it through the compiled and interpreted paths and compare the rendered HTML. Changing a query's result fields should exercise the template code that reads them, instead of leaving me to discover problems between separately tested tools while building the website.
I'd like one Piko release to settle which versions belong together, for the parts I supply. That includes the command-line tools. A tool generating Go for a different release from the application running it should report that mismatch directly.
What happens when a client needs a storage backend I haven't included? The application receives a storage implementation through an interface. I can pass an adapter behind that interface. That's dependency injection.
And its version? The application can supply an adapter with a release history of its own, so pinning Piko still leaves me choosing which version of that adapter belongs with it.
The adapter needs a clear Piko release to target. Checking that target when it's connected would catch a mismatch at the join. Otherwise I've brought the tools together and left the same version guessing game at the point where somebody extends them.
A small name
Piko means small. The idea was a small, complete engine that does everything I need, and the name felt right when I started bringing the projects together.
I can already see it won't stay small for very long.
It keeps absorbing more shared code. I like having somewhere for those pieces to go, even if the name is becoming an optimistic description of the size. It still feels like one system to me.
I'm aiming to open-source it next year.