Apollo data source and dataloader both support cache, why we still need data source cache, what problem apollo data source can solve while dataloader cannot. This article is trying to demystify this question.
When we develop graphql server using apollo server with REST api as the backend, we will use apollo datasource as recommended.
As the document says:
Data sources are classes that encapsulate fetching data from a particular service, with built-in support for caching, deduplication, and error handling.
Did you notice, data sources built-in support for caching? But how it support cache, the document itself doesn’t explain well.
Let’s…
In the last article, I discussed to use runtypes
to connect static types and runtime check. The theory behind is runtypes
has its own definition language, which can convert to a runtime check function and a static typescript type. By doing that we can remove the duplication across the two world.
It is awesome, however one of the biggest cons of this approach is: runtypes
defined a good definition language but it is not well known. Because of that, it is less possible to create a strong ecosystem for different scenarios.
For example, recently I am working on a REST…
Typescript introduced type system into javascript, but it is only existed till compiled into javascript. When we run those compiled code in runtime, all the types are disappeared.
This might not be a big issue, because in most case we can verify all the data type statically.
But how about the inputs from outside? A typically example is we need to fetch data from some REST APIs. We definitely cannot verify the inputs statically.
Let’s give a example, check the following example:
type Person = {
name: string;
films: string[];
};const fetchPerson = async (id: string): Promise<Person> => {…
Quite often, when we develop npm packages, we want to test them as a consumer. In order to test, if you think you have to publish it, you are out. There are at least three ways to make your life a lot easier.
Before we jump into the three method, let’s image the below scenarios we want to test:
GraphQL is cool, it exposes the exact contract between frontend and backend in details.
However, when you try to use it, there is still gaps between GraphQL and the host programming language. For example, mostly frontend project is using typescript, while GraphQL is strong typed contract but still not typescript.
This situation is like when we develop SQL based application by using Java. At that time, we have ORM, stands for Object Oriented Mapping, which is a standard tool mapping object structure and sql relationship, and allow developer to access SQL database by knowing only JAVA or other object oriented…
When we stated to use useEffect and slowly put more and more logics in the effect, it is very easily end up with a long dependency list because of the eslint exhaustive-deps rule.
We provide an `exhaustive-deps` ESLint rule as a part of the `eslint-plugin-react-hooks` package. It warns when dependencies are specified incorrectly and suggests a fix.
For example, the original goal of the effect is to execute it when the A prop is changed. However, because we end up with other props in deps list like func1 prop and obj1 prop, the effect triggering logic became either A, func1…
useEffect is the most widely used hook in React. It is handy and looks easy to use, but you must experience infinite loops or some unexpected result when using useEffect. In this article, I try to give you some tips to avoid those typical pitfalls when using it.
The definition of useEffect is below:
function useEffect(effect: EffectCallback, deps?: DependencyList): void
type EffectCallback = () => void | (() => void | undefined)
type DependencyList = any[]
There are three factors in useEffect, effect, cleanup, and deps. The key point is effect. We all know useEffect is to wrap side effects…
Graphql becomes more and more mainstream, and Graphql schemas first is becoming the recommended practice when starting a new project. It’s critical important to design a solid Graphql Schema which can be stable when facing future changes.
When I saw there is an egghead course called Designing Graphql Schemas, I joined. After watching all episodes in an afternoon, I learned a lot how to design robust schema. Thanks Nik Graf.
In this article I share what I learned, but I still encourage you to watch the whole cause by yourself.
Supposing we are using Apollo Server, it has built-in mock…
I use nodejs to develop a simple app talking to `sql server` like below:
import Knex from ‘knex’
const knex = Knex(…)// create the table
knex.schema.createTable(‘People’, function(t) {
t.string(‘name’).notNullable()
t.string(‘title’)
t.unique([‘name’, ‘title’])
})
What the above did is create a table called `People` and create a unique index on `name` and `title`. Then I insert two records with different value. It is fine.
// insert two records with different values, it is fine
knex(‘People’).insert({name: ‘ron’, title: ‘Mr.’})
knex(‘People’).insert({name: ‘aaron’, title: ‘Dr.’})
Next try is to insert two records with same values, I will expect to see exception would happen…
Full Stack Dev