Were you ever unsatisfied enough with an existing framework that you took the completely crazy step of rewriting it?
Well, that just happened to Ashley Davis. He's just finished rebuilding GraphQL in TypeScript.
We'll talk about "reinventing the wheel". Why is it considered bad? When is it a good time to reinvent things?
We'll look at how the new query language was developed and see a demo of it in action!
3. What is GraphQL?
A language to query and update data
Very popular
Created by Facebook
Open source
It’s quite incredible
https://graphql.org/
4. What’s wrong with GraphQL?
Forced schema
Add a new language to your stack
Too big/complex
Time consuming to implement
Tedious to have to specify everything you want returned
9. Why reinvent the wheel?
For fun or education
But not at work
@ashleydavis75
10. Introducing MiniQL
Features
JSON-based query language
Implemented in TypeScript for use in JavaScript/TypeScript
No schema
All fields returned by default
Delegate features to the backend
Node.js or the browser
@ashleydavis75
PREP:
Wifi hotspot
Start slides on desktoip
Open source tree.
Start timer.
Hi everyone,
My name is Ashley Davis.
I’m the author of a new book that’s about to be published called Bootstrapping Microservices.
This book is practical and project-based guide to building applications with microservices.
I’m also the CTO of Sortal and we are helping businesses manage their digital assets with machine learning.
I hope everyone out there is doing ok through the pandemic.
I hoping that soon we’ll all be able to meet up again in person.
Please feel free to get in touch with me via Twitter.
My handle is ashleydavis75 and you’ll see that printed at the bottom right of each slide.
I’m going to share screen now so you can see my slides.
!! Share screen !!
“To reinvent the wheel” means to rebuild something that has already been built before.
The connotation is that reinventing something is pointless and a waste of time, because somebody has already done it before.
In general this is a good warning.
And you should be careful where you invest your time and focus.
In this talk we’ll explore when it’s ok to reinvent the wheel.
And we’ll take a look at my new open source project called MiniQL.
I’ll start with some background on what I’m talking about tonight.
To make a long story short I’d really like to use GraphQL, I think it’s pretty awesome, but it didn’t quite fit my needs.
So a few weeks back I decided to create my own query language which I’ve called MiniQL.
It’s pretty much like GraphQL but much smaller.
I had some good reasons for doing this that I’m going to talk about soon.
And I can assure you that it’s not just because I’m crazy.
I am a little bit crazy. So there is that.
I implemented the core query engine for MiniQL in a very short amount of time.
And that’s because it is very small.
I’ve actually put a lot more effort into examples and documentation of MiniQL than I did for the code.
This is interesting in itself.
That something can be so simple to code and yet quite difficult to teach to other people.
And that’s because it’s very abstract.
After this experience I wanted to talk about MiniQL itself.
How it was built.
How it works.
And why I chose to reinvent the wheel on this occasion.
For those you that don’t what GraphQL is, I’ll explain it quickly.
These are the facts at a glance..
GraphQL is a language to query and manipulate data.
It’s very popular.
It was created by Facebook.
It’s open source.
There’s a link on the slide there in case you want to learn more about GraphQL and I’ll repeat that link on the last slide as well.
If you had thought that I don’t like GraphQL you are quite wrong.
I actually think it’s quite incredible.
I wanted to use GraphQL so much that I decided to lovingly rewrite the parts of it that work best for me.
So if GraphQL is incredible why don’t I want to use it?
Well there’s a time and place for GraphQL.
I’ve seen it work really well when I was contracting.
But I tried to implement it for my startup and it didn’t fit.
The first problem was having to have a schema.
For my startup I need to rapidly evolve and iterate our product so we can experiment to create the best product for our customers.
One of my aims in this effort is to reduce the cost of experimentation.
Not using a schema is one thing that helps with that.
The cost of defining a schema, updating it as the data evolves and migrating the database is a headache I don’t need and don’t want.
I don’t want to have create a schema for every microservice, so when it came to define a schema for my application’s data I just had to say no to GraphQL.
There are some other issues of course.
GraphQL adds an extra language to your stack that you and the other developers have to learn.
You might not want to bring onboard that extra complexity.
All things considered that isn’t a huge deal for me, but still I’d prefer not to add new languages if I can avoid it.
Also GraphQL is big and complex. It takes time to learn and it takes time to implement.
And I find it really tedious having to specify all the fields in the data that you want returned.
For me and my startup the barrier to entry to GraphQL was too high.
So I started thinking about what it would take to recreate it in a minimal form.
So this leads to the most important question in this talk.
When is it ok to reinvent the wheel?
We are often told that reinventing the wheel is a bad thing.
Some people will say we should never reinvent the wheel.
And generally that’s a good principle.
But consider this…
If no one ever reinvented anything we’d never have better things.
We’d still be stuck with the tired old programming languages, databases, operating systems and so on.
There are times when reinventing the wheel is necessary for innovation and evolution.
But unfortunately we can only see this in hindsight.
When you make a better wheel that is successful you will be praised.
But the only way to get to that success is to make it past all the people that are telling you not to reinvent the wheel.
Another reason is that the existing wheel doesn’t do what you want.
This is what happened to me. GraphQL didn’t fit my needs so I created my own small query language.
You could also be motivated to build a better wheel.
I don’t think I could build something better than GraphQL, it’s already pretty good so that’s not my motivation.
But if you think you could reinvent something and surpass the limitations that came before, well that’s a pretty good motivation.
Of course it’s also perfectly ok to reinvent things for fun or education.
That’s actually a fantastic way to learn new things and get experience as a developer.
Pick some technology that you really like and try to make your version.
I say try because you might start building it then realize that it’s actually really difficult and have to give up.
At this point I’d like to say that this is ok as well.
Starting a project, learning something useful then dropping it is perfectly ok.
When we do any kind of hobbiest coding for education we should stop coding as soon as we have learned what we wanted to learn.
Ok but just don’t do this on work time.
If you are rebuilding something for fun or education please do it on your own time.
So please without further ado let me introduce you to MiniQL.
It’s a tiny JSON-based query language inspired by GraphQL.
This was born out of desire to use GraphQL but then my frustration in not being able to use it.
MiniQL is implemented in TypeScript for use in JavaScript and TypeScript.
The query language is just JSON of course so it’s possible in the future you might see MiniQL implementations in other languages besides TypeScript.
MiniQL doesn’t require you to define a schema and all fields are returned by default.
One of the things that’s important for keeping MiniQL small is that many features can be delegated to the backend.
So whatever database you are using in the backend you can make use of whatever special features it has for searching, querying and pagination.
My first implementation of MiniQL works both in Node.js or the browser.
And I’m about to show you some examples.
Show interactive example.
- Star wars data
- JavaScript, even though MiniQL is TypeScript
MiniQL + miniql/inline
Entirely browser based example of MiniQL.
React / create-react-app / hooks
Ant design
Tailwind
MonacoEditor
Show GitHib page, with instructions to get it started.
Show MiniQL on GitHub.
Show other examples.
Show MiniQL org on GitHub
Explain what the other projects are.
Show MiniQL code and tests.
Show core engine.
Note that it’s TypeScript.
Show commit history.
SourceTree
Emphasize small commits.
Each change has automated tests.
This is a good example of test driven development.
If you want to learn more about development, you could follow along with each commit to see step by step how this project was developed.
I’m basically done.
There’s a bunch links here that you might find useful.
There’s a link to MiniQL and the interactive example that I demonstrated earlier.
There’s a link to GraphQL if you want to learn more about that.
I always start my TypeScript projects with my TypeScript template, so there’s a link there to that if you’d like to try it out.
And also for anyone to learn about microservices there’s a link at the end to my new book Bootstrapping Microservices .