LogRocket Blog

You mean a filter to transform the query from A (say, with syntactic sugar syntax) to B (with final syntax)?

I'm actually doing something similar in GraphQL by PoP, on a couple of levels: queries are decoupled into requested and executable, where they can differ in syntax, directives attached to them, and others. I wrote a bit about this strategy here:

https://blog.logrocket.com/adding-directives-schema-code-first-graphql-servers/

In addition, GraphQL by PoP does not understand the GraphQL syntax. It understands another syntax, that I've called PQL:

https://graphql-by-pop.com/docs/extended/pql.html.

PQL is a superset of the GraphQL query, so GraphQL by PoP transforms from GraphQL to PQL syntax and then executes it. For instance, this GraphQL query:

```

query {

posts {

excerpt

titleES: title @translate(from:"en",to:"en")

}

}

```

is converted to this:

```

posts.excerpt|title@titleES<translate(from:en,to:es)>

```

Check it out here:

https://newapi.getpop.org/api/graphql/?query=posts.excerpt|title@titleES%3Ctranslate(from:en,to:es)%3E

This works great. Only issue is when there's some error when retrieving the data, and I need to return an error message with the path to the problem in the query. In that case, the path corresponds to the transformed PQL query, not the original GraphQL query. (It would be possible to have a mapping for them, token by token, but I haven't coded it)

---

Btw, connected to PQL, GraphQL by PoP can support the embeddable…

For docker images in general: the best way is to do multi-stage builds [0][1]. You will need to (re)write your Docker files to use this.

A quick-and-dirty way that doesn't require rewriting is just to use the experimental --squash flag[1] (i.e. add: --experimental --squash) when running docker (you can also turn on --experimental permanently by putting
{ "experimental": true } into docker's /etc/docker/daemon.json file. And, on a Mac, you can open the Docker app and there's a checkbox to turn on experimental features and then you can just use --squash in the terminal).

Anecdotally, I had a 4.67GB docker file that --squash reduced to a little over 1GB. However, a rewrite of the docker file to do a multi-stage build took that 4.67GB file down to just under 0.5GB.

P.S. Pro-tip: if you want to speed up your docker builds, if you're using 18.06 or higher, you can use use buildkit [2]. Again, anecdotally, on a 6-core Macbook from 2019 I think I got a 30% speedup or so -- your mileage may vary (a colleague with an 8-core machine I think got a 50% speedup -- it's been a while, so these percentages may be a bit off, but you get the idea).

It was also an experimental feature early on, so you needed to have experimental features turned on (as described above with --squash). With later versions you don't need to do that -- check your version's documentation.

Anyway, you can either set an environment variable to use it i.e. export DOCKER_BUILDKIT=1 or you can set this permanently…

I'm not talking about fizzbuzz or algorithm problems, I'm talking about programming assignments, the first one I ever had was something like the following:

Please use the HN API to build a tree view of HN comments that allow you to see what the top posts are on a day where you can drill down to see comments on the posts and the top commenters, use client side vanilla JavaScript code to get data, allow persistence of data to local storage so that if the computer goes offline you will be able to still read content. Separation of concerns, nice code structure, and a nice presentation will impress us.

Suggested time: 4 hours.

Others, here is a partially completed project set up, some mock data, a link to a technical specification of a data format you are probably unfamiliar with that you need to also use a graphQL endpoint to query and build a table view of Apartment listings with pictures of the apartment, the location, the zip code, the phone number of country, rental price. Users should be able to login and see the latest apartment listings, it should be possible to sort by latest updated listing and by rental price. Sorting should persist between pages. Tech stack to use React, Sass, Webpack, a nodejs static server.

time: 4 hours.

This one was interesting because it is the only one I have ever had where I managed it in EXACTLY 4 hours (except for ones that were more like use what language you like to do this algorithm)

I even made a cool SVG log in component based on…

lukeed has several extremely popular npm packages/libs which share a lot in common:

- their twitter following is used to boost newly released packages

- they were released as alternatives to existing packages/libs with the flashy promise of being smaller, less complicated, faster

- negative feedback is rebuffed as "an attack"

- they're all very green

- they lack features and stability of the more mature packages they aim to supplant

- once released and popular, they cease getting frequent updates

Now, yes this is a generalization. It doesn't apply to all of their packages, and not at the same point in time. But there is a pattern there. Some quick diving into the author's Github account, and their more popular repos shows the pattern. It's also clear that this was a choice made by a Svelte contributor to use their own package for "official" support in Svelte Kit.

When it comes to polka itself, I just don't get why a maturing framework like Svelte would choose something whose only real advantage lies in micro-benchmarking porn [1]. Speculation aside, I'm surprised the Svelte team didn't look at that choice through a lens of higher scrutiny. Koa would have been an infinitely better choice in my personal opinion, and there are several community-driven setups [2][3] for it.

[1] https://github.com/lukeed/polka#benchmarks

[2] https://github.com/kaladivo/svelte-kit-koa-boilerplate

[3] https://blog.logrocket.com/sapper-svelte-tutorial-2021/

The broader idea of “pass a value between functions without naming it in the caller” crops up in a few other places outside FP.

In Rust there is the “builder pattern”[0] where the builder isn’t mentioned directly:

ByValueBuilder::new() .with_favorite_number(42) .with_favorite_programming_language("Rust") .build() In OO land they are called “fluent interfaces”[1], commonly used when building SQL queries while only mentioning the final query at the end:

query = translations .Where(t => t.Key.Contains("a")) .OrderBy(t => t.Value.Length) .Select(t => t.Value.ToUpper()); Especially in the query builder example, since it is essentially building up an AST, the type of the top-level object can change in each call, but since it isn’t named it also doesn’t need to be typed, so there’s no issue with variable shadowing etc.

[0] https://blog.logrocket.com/build-rust-api-builder-pattern/ [1] https://en.m.wikipedia.org/wiki/Fluent_interface

Magic-RegExp aims to create a compiled away, type-safe, readable RegEx alternative that makes the process a lot easier. https://blog.logrocket.com/understanding-magic-regexp-regexp...

example from blog:

import { createRegExp, exactly, wordChar, oneOrMore, anyOf, } from "magic-regexp";

const regExp = createRegExp(

exactly("http") .and(exactly("s").optionally()) .and("://") .optionally() .and(exactly("www.").optionally()) .and(oneOrMore(wordChar)) .and(exactly(".")) .and(anyOf("com", "org", "io")), ["g", "m", "i"] );

console.log(regExp);

/(https?:\/\/)?(www\.)?\w+\.(com|org|io)/gmi