By developers, for developers — DevCon 2019
DevCon is a brand new web and mobile development conference which we are all hoping to grow into by-the-community for-the-community annual event. The first edition of DevCon was held a couple of days ago and included several in-depth talks about the newest technologies and trends in the web and mobile development world.
From React Hooks, Electron and ProtoBufs, to GraphQL and Text-Independent Speaker Identification, the 1-day conference covered a lot of topics mostly intended for web developers. Even though all the talks were excellent, as a mobile and a backend developer I found several of them to be quite interesting and practical. Following are my notes on 2 of them, tidied up a bit.
Introduction to GraphQL
GraphQL is a query language for APIs that is still not popular enough despite its amazing capabilities and potential. You can basically describe your data and give your clients the power to ask what they want, and get nothing less, nothing more.
As a more efficient and flexible alternative of REST, it can be used on a variety of different frameworks and platforms, and you can use any language you want on the server side.
GraphQL APIs are organized in terms of types and fields instead of endpoints. Expose a single endpoint, define a schema that can be shared between the team and everyone can start working independently.
Used by Facebook, Github, Twitter, Pinterest, and Paypal, GraphQL gains its popularity by being a “revolutionary” way to think about APIs. In reality, there are several different concepts that make a big difference:
- Smooth collaboration between backend and frontend teams by defining a schema vs. coordinating teams and waiting on the backend team
- One exposed endpoint vs. many
- Solves two common REST problems: over-fetching and under-fetching — the client downloads more data than needed or makes additional requests in order to fetch everything necessary.
- No versioning: you can add new types and fields to your API without impacting the existing queries.
- Subscribing to real-time updates: get updates on the client side every time something changes on the server side.
- Ease transition to microservices
- Centrally manage and secure your API
Will it replace REST?
While many companies have already started using GraphQL it still doesn’t as wide of an audience as REST does. It has no major drawbacks, but there are some separated opinions on whether or not you should use REST or GraphQL. It would be really nice if we can see a real-life example where GraphQL was used and it shouldn’t, and vice versa.
What to read next?
Stefan Janev’s talk was excellent, but as the title says, it is only an introduction since this is a topic that can not be covered in one page. For the curious ones, I’ve assembled a fair list of blogs, tutorials, and documentation where you can learn more about GraphQL.
- From Zero to GraphQL subscriptions
- What is Apollo client and what does it do?
- Real-time GraphQL subscriptions
- Is GraphQL the end of REST APIs?
- REST vs. GraphQL
- GraphQL schema
- GraphQL docs
- The problems of “Schema-first” GraphQL Server development
- Advanced GraphQL tutorials
Writing correct programs
Another talk that I considered to be really interesting and a little bit different than what we see every day is Boro Sitnikovski’s talk on correct programs. We, developers, have the daily struggle of making programs doing what they are intended to, nothing less, nothing more.
So, how do we write a correct program?
Let’s take left-pad as an example. What this program actually does is adding a character repeatedly until the result string reaches the specified length. Usage:
leftpad(“.devcon.dev”, 14, “w” )should produce:
“www.devcon.dev”You can take a look at the tests for this library, where a lot of edge cases are covered. But can you cover ALL cases with TDD?
Can you prove that:
leftpad(“devcon”, 6, x) == “devcon”for all possible x’s?
This is where the math comes into play since it is the core concept behind functional programming. With TDD being limiting in some cases, we can achieve our software correctness by providing proof of correctness.
“A proof of correctness is a logical proof that the software is functioning according to our given specifications”
You specify a set of theorems or predicates for your function and prove them.
“What is a proof? A proof is a justification of the truth of a proposition.”
With valid proofs, we can cover all possible cases and be more confident that the code does exactly what it is intended to do. You can do this by using a functional programming language with dependent types.
As stated in Idris docs:
Dependent types allow types to be predicated on values, meaning that some aspects of a program’s behavior can be specified precisely in the type. Its features are influenced by Haskell and ML.
You can continue reading about functional programming and dependent types with Gentle Introduction to Dependent Types with Idris by Boro Sitnikovski and Typechecking in the lambda-Pi-Calculus Modulo : Theory and Practice by Ronan Saillard.
Hopefully, this will tackle someone’s interest and continue to learn more.
Last, I would also like to thank everyone involved in organizing this conference with a pretty solid line-up. This was a long-awaited event and a great initiative with bright minds and excellent talks!
