
# Monthly meeting

Every month we try to have a public meeting for [Strawberry GraphQL](https://strawberry.rocks). 

You can find [the notes about the meeting here](https://github.com/strawberry-graphql/strawberry/discussions/1251); this time we had more people than usual, even though not many did add their participation to the notes.

We discussed a few topics, like the [direction and goal of Strawberry](https://strawberry.rocks/docs/general/why), whether we should integrate Strawberry GraphQL Django into core or not, how we will get to v1.0 and other things, make sure you checkout [the notes here](https://github.com/strawberry-graphql/strawberry/discussions/1251) if you're curious and, as always, feel free to ask us any questions.

# PRs

I felt extremely tired this week, so I didn't do much work around Strawberry, I did review some PRs though:

[Bryce](https://github.com/brycebeagle) made a [PR to fix a couple of issues with Generics, LazyTypes and Enums](https://github.com/strawberry-graphql/strawberry/pull/1235). This has been merged and released now.

[Matt](https://github.com/Matt343) made a [PR to add support for creating interfaces from Pyndatic types](https://github.com/strawberry-graphql/strawberry/pull/1241). Thanks to Matt again for improving the Pydantic integration!

[Jon](https://github.com/jkimbo) made a [PR to fix an issue with optional inputs/variables](https://github.com/strawberry-graphql/strawberry/pull/1249)

And finally [Olesia](https://github.com/Zlira) made a [PR to raise 400 when sending a malformed query to the ASGI integration](https://github.com/strawberry-graphql/strawberry/pull/1260). This was Olesia first contribution 👏

# Fin

Hopefully next week will be better. I think I'll spend time reviewing issues, as hacktober fest is coming soon and I'd love to have "good first" issues for new contributors!

---

Written at home 😴


19 September 2021

Open-source updates


# PyRight

A while ago I started a PR to improve the support for PyRight. This was prompted by [this PEP proposal](https://github.com/microsoft/pyright/blob/main/specs/dataclass_transforms.md). The PEP proposes a standard way for "tagging" function that do similar transform to dataclasses (like we us, Pydantic, SQL Model and more). This allows to use pure python code to define function/decorator that transform classes by adding methods like `__init__`, `__eq__` and so on.

Previously we could only do this with MyPy by using a (complex) plugin. Hopefully the PEP will be accepted at some point, meaning that all python type checkers implementing the spec will properly type check Strawberry and other libraries adopting the PEP.

I did hold off this PR for a bit since I wanted to make sure we supported most of our APIs and I'm very happy to have [managed to influnce the PEP proposal](https://github.com/microsoft/pyright/commit/e68dff84cbed26e2c6e1625e53ea21c35899a282) to make it a bit easier for libraries to take advantage of the proposal, even when they don't fully dataclasses's semantics, like Strawberry 😊

For example, before that change the following example would result in a class that accepted one parameter, `field_x`, at least for the type checkers:

```python
def get_x() -> int:
    return 42

@strawberry.type
class Query:
    field_x: int = strawberry.field(resolver=get_x)
```

while at runtime it wouldn't actually accept any parameter since fields with resolvers (in Strawberry) don't need a value (the value comes from the resolver function). To fix this we can follow dataclasses' semantics and pass `init=False` to the `field` function:

```python
@strawberry.type
class Query:
    field_x: int = strawberry.field(resolver=get_x, init=False)
```

But this is quite annoying, since the `init` parameter won't be used by Strawberry (at least when passing resolvers).

Luckily we can solve this by using overloads and `Literals` (if you're curious to see how it works see the [spec](https://github.com/microsoft/pyright/blob/main/specs/dataclass_transforms.md)).

By typing the `field` function something like this:

```python
@overload
def field(
    *,  # Note the omission of `resolver`
    init: Literal[True] = True,
) -> Any:
    ...


@overload
def field(
    *,
    resolver: Callable[[], T],
    init: Literal[False] = False,
) -> T:
    ...
```

[See here for the full implementation](https://github.com/strawberry-graphql/strawberry/blob/0ec09a63eba826742e8d046c00d7b439b32302d4/strawberry/field.py#L294-L358)

we can tell the type checker that when `resolver` is passed `init` is always `False`, and so we don't have to pass it explicitly 💯

Big thanks to Eric for accepting the suggestion and implementing it so quickly!

# Actions

I've also spent some time cleaning up our GitHub actions and moved some of our actions to dedicated repos, hopefully some people might re-use them.

There's an [action to get information about a PR](https://github.com/strawberry-graphql/get-pr-info-action). This action works in the PR itself but also on master after the PR has been merged (it finds the PR from the commit). We use this for generating the twitter cards and for inviting contributors to our organisation.

There's a [couple of actions for our tweet workflow](https://github.com/strawberry-graphql/tweet-actions). They allow to get the tweet text from a `TWEET.md` file and to validate the text. This action is quite coupled to our workflow, but I'd love to make it more reusable, so if someone needs this, let me know!

I've created a [new action to invite contributors](https://github.com/strawberry-graphql/invite-to-org-action) to our organisation automatically. I did try to use a pre-build action but it wasn't working so I've made our own :)

We were doing this manually in the past, but now we don't have to anymore, it loses the personal touch, but it is so easy to forget to invite people!

Again, if you want to re-use these actions let me know! Always happy to improve them 😊

# Pull Request reviews

Here's the list of PRs I managed to review in the last couple of weeks:

[A PR to add fragments to the `selected_fields` property on the info parameter](https://github.com/strawberry-graphql/strawberry/pull/1213) by [Jon](https://github.com/jkimbo)

[A PR to fix an issue with the export-schema command](https://github.com/strawberry-graphql/strawberry/pull/1233) by [Matt](https://github.com/Matt343)

[A PR to fix using union types with Pydantic types](https://github.com/strawberry-graphql/strawberry/pull/1231) by [Matt](https://github.com/Matt343)

[A PR to fix optional values conversion from Pydantic types](https://github.com/strawberry-graphql/strawberry/pull/1229) by [Matt](https://github.com/Matt343)

Big props to [Matt](https://github.com/Matt343) for sending 3 PRs!

[A PR to allow any version of opentelemetry before 2.0](https://github.com/strawberry-graphql/strawberry/pull/1226) by [Michael](https://github.com/ossareh)

[A PR to raise an exception when using unions or interfaces as inputs](https://github.com/strawberry-graphql/strawberry/pull/1222) by [Mohammad](https://github.com/MAM-SYS)

# Fin

I was mostly off during the last two weeks but I managed to do some useful work, also I've noticed that Strawberry is gaining quite a bit of traction lately, which is super nice!

Written in Venice 🇮🇹


13 September 2021


# PR reviews

[Jon](https://github.com/jkimbo) sent a PR to change the pinned version of
GraphQL-core. We need this because GraphQL-core doesn't really follow semantic
versioning, so minor changes could include breaking changes.

PR here:
[https://github.com/strawberry-graphql/strawberry/pull/1162](https://github.com/strawberry-graphql/strawberry/pull/1162)

[Jon](https://github.com/jkimbo) also made a PR to lazily access properties in
the `info` object, this was a performance regression from when we introduced our
custom `Info` type.

PR here:
[https://github.com/strawberry-graphql/strawberry/pull/1165](https://github.com/strawberry-graphql/strawberry/pull/1165)

As a followup to Jon's PR [A. Coady](https://github.com/coady) made a PR to
cache the `selected_field` property so that multiple access won't recalculate
it.

PR here:
[https://github.com/strawberry-graphql/strawberry/pull/1167](https://github.com/strawberry-graphql/strawberry/pull/1167)

[Joe Freeman](https://github.com/joefreeman) sent a very interesting PR to add
support for background tasks in the ASGI implementation. Now you can start
background tasks by doing something like this:

```python
from starlette.background import BackgroundTask

@strawberry.mutation
def create_flavour(self, info: Info) -> str:
    info.context["response"].background = BackgroundTask(...)
```

This is a pretty cool feature of Starlette that I didn't about!

PR here:
[https://github.com/strawberry-graphql/strawberry/pull/1168](https://github.com/strawberry-graphql/strawberry/pull/1168)

Joe also sent a PR to add support for opentelemetry 1.0. This is something we
should have done a while ago, so I'm glad Joe spent a bit of time on it!

PR here:
[https://github.com/strawberry-graphql/strawberry/pull/1169](https://github.com/strawberry-graphql/strawberry/pull/1169)

# Bug fixes

I've also made two PRs related to opentelemetry. One to fix a small issue with
the version number for opentelemetry and one to fix an import error that was
happening when you didn't have opentelemetry installed (since it is an optional
dependency).

PRs:

[https://github.com/strawberry-graphql/strawberry/pull/1170](https://github.com/strawberry-graphql/strawberry/pull/1170)
[https://github.com/strawberry-graphql/strawberry/pull/1171](https://github.com/strawberry-graphql/strawberry/pull/1171)

I've also made a PR to improve mypy support for `create_type` as mypy doesn't
yet support creating new types from functions. Our plugin now changes the return
type of `create_type` to be a `TypeAlias` and now you can do this without
getting an error:

```python
import strawberry
from strawberry.tools import create_type

@strawberry.field
def name() -> str:
    return "foo"

MyType = create_type("MyType", [name])

class Query(MyType):
    ...
```

PR here:
[https://github.com/strawberry-graphql/strawberry/pull/1175](https://github.com/strawberry-graphql/strawberry/pull/1175)

Speaking of mypy, I've gotten back to the PR to add support to PyRight, but I
haven't yet finished it as there's a couple of things I want to improve first.
Also I've asked the maintainer of PyRight to see if we could get some support
for `strawberry.field` but alas this won't happen as the solution for adding
typing support is tied to the dataclasses semantic and `strawberry.field` don't
match one to one to dataclasses.

PR here:
[https://github.com/strawberry-graphql/strawberry/pull/922](https://github.com/strawberry-graphql/strawberry/pull/922)

I've made a PR to add support for async directives. This also fixed a bug when
using directives and async extensions. I think we should make sure async works
for all the use cases as it will probably become more important in the future.

PR here:
[https://github.com/strawberry-graphql/strawberry/pull/1179](https://github.com/strawberry-graphql/strawberry/pull/1179)

I've also made a PR to accept click 8.0 as a dependency. I think this was asked
on Discord a while ago, so it was about time to fix it :)

PR here:
[https://github.com/strawberry-graphql/strawberry/pull/1181](https://github.com/strawberry-graphql/strawberry/pull/1181)

# Apollo Federation

We also merged the PR that I made to add a
[guide on how to use Apollo Federation with Strawberry](https://strawberry.rocks/docs/guides/federation).
I did open this PR one year ago 😮 and I'm glad I finally made time to finish it
as people have requested it.

I've also made a companion repository for the docs, available here:
[https://github.com/strawberry-graphql/federation-demo](https://github.com/strawberry-graphql/federation-demo)

<Tweet tweetLink="strawberry_gql/status/1432443214699667458" align="center" />

# Fin

I think this was a good week! I still have a lot of PR to review, but the number
of open PRs seems to be going down over time. Also thanks to Jon and Bryce for
reviewing and merging PRs over time ♥️

---

Written somewhere near Venice 🇮🇹


30 August 2021


# Strawberry GraphQL Django

This week I've merged and release the
[PR from Vojtěch Dohnal](https://github.com/strawberry-graphql/strawberry-graphql-django/pull/50)
that updates Strawberry GraphQL Django to support the latest release of
Strawberry.

I think we should start thinking about merging Strawberry GraphQL Django into
Strawberry itself, it might be a good topic for the next monthly meeting.

# Feedback form

As I mentioned in the previous post we added a feedback form on our website and
we already got some feedbacks from our users. For example one feedback was
related to the lack of documentation on Apollo Federation support. I have a PR
for this that I need to finish. Having these feedbacks will help us prioritize
the docs that are needed the most.

Hopefully next week I'll be able to finish that PR and also work on other
documentation pages.

# Code reviews

Me and Jon merged a few PRs this week, most of them are by
[Jonathan Ehwald ](https://github.com/DoctorJohn) 💯

The first PR is to remove our dependency on hupper, we were using it to have
some sort of auto-reload feature. We have switched to using uvicorn's reloader
instead, so we have one less thing to maintain and one less dependency to
install.

PR:
[https://github.com/strawberry-graphql/strawberry/pull/1114](https://github.com/strawberry-graphql/strawberry/pull/1114)

Jonathan also added a couple of new features related to support async in
extensions and permission classes. I think async in python is going to be used
more and more over time and we should make sure we have proper support for it.

Jonathan's PRs added support for async in extensions and permission classes
without making the API cumbersome. You can basically mix and match async and
sync methods and they should just work. Really excited by this!

PRs:
[https://github.com/strawberry-graphql/strawberry/pull/1142](https://github.com/strawberry-graphql/strawberry/pull/1142)
[https://github.com/strawberry-graphql/strawberry/pull/1125](https://github.com/strawberry-graphql/strawberry/pull/1125)

We also got a nice PR to improve error logging, this was done by
[Ivan Gonzalez](https://github.com/scratchmex) along with a couple of other PRs
to improve docs for FastAPI and ASGI.

Definitely happy seeing people taking time to fix PRs and improve the library
overall. The error logging PR is quite nice as it makes it easier to debug
errors so it a nice dx improvement.

PRs:
[https://github.com/strawberry-graphql/strawberry/pull/1152](https://github.com/strawberry-graphql/strawberry/pull/1152)
[https://github.com/strawberry-graphql/strawberry/pull/1157](https://github.com/strawberry-graphql/strawberry/pull/1157)
[https://github.com/strawberry-graphql/strawberry/pull/1156](https://github.com/strawberry-graphql/strawberry/pull/1156)

[Michael Ossareh](https://github.com/ossareh) also sent a PR to fix an issue in
the docs! Thank you! ❤️

PR:
[https://github.com/strawberry-graphql/strawberry/pull/1161](https://github.com/strawberry-graphql/strawberry/pull/1161)

And finally Jon sent a PR to prevent automatic updates to graphql-core's minor
versions. This is mostly related to the fact that graphql-core doesn't really
follow semantic versioning so minor releases might break compatibility.

PR:
[https://github.com/strawberry-graphql/strawberry/pull/1162](https://github.com/strawberry-graphql/strawberry/pull/1162)

# Python 3.10

I spent a tiny bit of time trying to merge my PR to add support and test for
Python 3.10, but unfortunately Poetry still doesn't work on Python 3.10. So I'll
wait a bit more for that, we still have a bit of time before Python 3.10 is
releases, and tests should be passing, so we won't have a lot of work to do.

# Tweet workflow

I've also made a tiny change in the tweet workflow to support new lines better.
But apparently it didn't work well enough:

<Tweet tweetLink="strawberry_gql/status/1429571197164040194" align="center" />

I think I'll try to move the github action we use for tweets to a new repo in
future as it will make it easier to test and it might also be reused by others.

# Fin

A bit of a slow week but I have definitely made some progress, I'll be
travelling at end of next week so I might not have a lot of time to write a
report or to do reviews, but we'll see!

---

Written at home 😊


22 August 2021


# Feedback form

I think this is probably the most interesting thing that I've worked on this
week. We were discussing documentation on our discord server (we still have
loads to do to improve it) and [Hannes](https://github.com/2malh) suggested to
implement a feedback form so we can understand what the pain points of our docs.

I've implemented a basic form that can be used to send us some feedback about
our documentation. Hopefully this helps with prioritising docs that are
confusing/missing/lacking. We'll see!

I was also thinking of doing some one on one session with people using
Strawberry and see how they use the library, to make sure the documentation is
well understood and to see if we can make it even easier to use. If you're
interested in doing something like this let me know!

# Code reviews

I've spent a bit of time review a few PRs on both Strawberry and Strawberry
Django. Hopefully the backlog will decrease over time.

Mark's PR is adding support for Chalice. You can see it here:
[https://github.com/strawberry-graphql/strawberry/pull/923](https://github.com/strawberry-graphql/strawberry/pull/923)

I did a merge with the main branch but something broke with MyPy. I'll fix this
either after publishing these notes or the day after. Then it should be ready to
merge :)

Jon's PR is another great addition to Strawberry and it will allow to override
default scalars and define new scalars on a per-schema basis. The PR looks
great, but there's a couple of things to sort out before merging.

You can see the PR here:
[https://github.com/strawberry-graphql/strawberry/pull/1147](https://github.com/strawberry-graphql/strawberry/pull/1147)

The last PR I reviewed is from [Vojtěch Dohnal](https://github.com/KundaPanda)
and it aims to make Strawberry Django compatibile with the latest version of
Strawberry. We did a lot of internal changes, so unfortunately we broke
compatibility with Strawberry Django. The PR looks great and I think I'll merge
and release in the next couple of days, just want to make sure the main
maintainer of Strawberry Django is happy with the changes.

PR:
[https://github.com/strawberry-graphql/strawberry-graphql-django/pull/50](https://github.com/strawberry-graphql/strawberry-graphql-django/pull/50)

# Duck typing fixes

I've also managed to make some time to fix a bug that prevented returning
non-strawberry types in resolvers where the field type was extending an
interface.

Strawberry supports duck typing, meaning you don't have to return instances of a
Strawberry types from resolvers as long as the shape matches. Unfortunately this
is broken for types that extend interface. I've made a PR to fix this, but I
need to double check the code is actually sound.

In future we also want to enable returning dictionaries in resolvers; sometimes
it is pointless to convert a dictionary (ie from a db or api) into a Strawberry
type if the shape is the same.

PR:
[https://github.com/strawberry-graphql/strawberry/pull/1150](https://github.com/strawberry-graphql/strawberry/pull/1150)

# Selected fields on the info parameter

[Aric Coady](https://github.com/coady) made a very useful PR a while ago and I
finally managed to merge it this week. It adds better support for finding out
what fields have been selected in a GraphQL query. You could use this to
optimise GraphQL queries for example.

PR:
[https://github.com/strawberry-graphql/strawberry/pull/874/](https://github.com/strawberry-graphql/strawberry/pull/874/)

# Bug fixes in the tweet workflow

There were a couple of issues with the tweet workflow I made last week, for
example the contributor name in the preview comment was always the name of the
last person that had sent a commit to that PR, which is not what I wanted; maybe
in future we need to work with multiple contributors on PRs, but for now this is
good enough.

In addition to that the workflow wasn't really working when non-core dev were
sending PRs since the GITHUB_TOKEN wasn't passed the workflow, switching the
workflow from `pull_request` to `pull_request_target` fixed the issue. Thanks to
[Bryce](https://twitter.com/ignormies) for the tip!

This also means I can fix the workflow for releasing docs in the same way!

PRs:
[https://github.com/strawberry-graphql/strawberry/pull/1140](https://github.com/strawberry-graphql/strawberry/pull/1140)
[https://github.com/strawberry-graphql/strawberry/pull/1136](https://github.com/strawberry-graphql/strawberry/pull/1136)

# Fin

This week I managed to review some long standing PRs, there's definitely more
work to do. I hope next week I manage to review more. We'll see. I also have
some new ideas for other features and projects related to Strawberry, but I
don't have much to share for the time being. Stay tuned for more in future!

---

Written at home 😊


15 August 2021


# Release cards

Oof, this took a very long time to make! But I'm happy with the end result. We
now have a couple of additional GitHub action workflows to send a tweet when a
release is publish. These workflow will extract the tweet from a `TWEET.md`
file, if it exists, otherwise there's a default message, they will also validate
the tweet to make sure they satisfy twitter's validation rules and will generate
a release card preview in the PR, so we can make sure the card looks nice. We
can also override the contents in case the release notes don't fit the card.

I've definitely learned a lot of GitHub action an hope to extract some of the
custom actions I've made to repos that can be reused by other, but I'll need to
clean up the code a bit 😊

Here's an example tweet created by this new workflow:

<Tweet tweetLink="strawberry_gql/status/1424485690650267649" align="center" />

So much better than the previous automated message!

I'm thinking of making the release-cards action more reusable, if it might be
useful for you let me know!

# Query validations

Speaking of releases, [Jon](https://twitter.com/jonnykim) implemented support
for validation rules and created a validation rules that allows to disabled
deeply nested queries.

This a really useful feature as it allows to create custom rules to make your
APIs more secure. We might add more built-in rules in future 😊

[https://github.com/strawberry-graphql/strawberry/pull/1021](https://github.com/strawberry-graphql/strawberry/pull/1021)

# pre-commit.ci

I've also removed our custom GitHub action to use
[pre-commit.ci](https://pre-commit.ci/), which appears to be faster and also
fixes the PRs when some checks change the files. I'm definitely liking it!

# Our monthly meeting

A while ago we decided to run monthly meeting to get feedback from the community
and be more open about the development of the library. We don't have a lot of
people attending these meetings and I think it is mostly because we don't really
do a good job at promoting them. We definitely need to automate the messages on
discord and Twitter so people have enough time to prepare for the meeting. Maybe
we should also post about the meetings in our newsletter. I'll try to make
sometime to automate the messages, hopefully there's a discord bot for that, or
I can use another GitHub action :D

# Fin

So yeah, this week I definitely spent a lot of time on the action work, but I
think it was worth it, as we will give more recognition to our contributors and
more useful tweets to our users 😊

Next week I'll start review old PRs, as they are piling up now!

See you next week and happy anniversary to my parents ❤️

---

Written at [Neighbourhood 🍕](https://www.neighbourhood-bar.co.uk/).


8 August 2021


# Django Cursor Pagination 0.1.5

There's finally a new version of Django Cursor Pagination! I've recentely been
granted permission to publish a new version of the package, so I did that today
:)

We use this package at [work](https://pollen.co) and we had pinned the git
commit that has fixed some small issues with the latest Django versions. But now
we can revert that to use normal dependencies, hopefully other people can do
this too.

# Release cards for Strawberry

This is taking more time than I wanted, but I manged to get some progress, we
have a brand new action that creates an image that can be used on twitter. It
will contain the contributor name, the version number and the release notes.

I have a work-in-progress PR that will use this action here:

[https://github.com/strawberry-graphql/strawberry/pull/1091](https://github.com/strawberry-graphql/strawberry/pull/1091)

The plan is to generated a card preview when there's a release note file. Then
we will generate the card again when we merge the PR and release a new version
and will also send a tweet with the image. I also want to mention the
contributor on Twitter, but we need a way to store their username (maybe a
TWEET.md file). I hope to get this done next week.

In the mean while don't forget to follow us on Twitter for updates:
[https://twitter.com/strawberry_gql](https://twitter.com/strawberry_gql)

# Changed the CDN for GraphiQL on Strawberry

This wasn't done or reviewed by me but I think it is worth mentioning, we
switched the CDN for GraphiQL from jsdeliver to unpkg to fix a loading issue.

Thanks to [Tim Savage](https://github.com/timsavage) for the PR!

[https://github.com/strawberry-graphql/strawberry/pull/1096](https://github.com/strawberry-graphql/strawberry/pull/1096)

# Other updates

As mentioned above I've spent most of my time on the release cards, I'm planning
to merge this PR in the next couple of days though:
[https://github.com/strawberry-graphql/strawberry/pull/874](https://github.com/strawberry-graphql/strawberry/pull/874)

This will make it easier to introspect the queries done by clients and see what
fields they have requested, for example you can use it to optimise Django
queries :)

We also rebooted a discussion on adding support for validation, this could be a
very useful feature, if you have ideas or suggestions feel free to jump in the
discussions!

[https://github.com/strawberry-graphql/strawberry/discussions/820](https://github.com/strawberry-graphql/strawberry/discussions/820)

See you next week!

Oh, and happy Switzerland national day! 🇨🇭

---

Written at [Rule Zero 🎲](https://www.rulezero.co.uk).


1 August 2021


# Internal refactoring

Really excited about the work that [Bryce](https://github.com/BryceBeagle) has
been doing on the internals of Strawberry; Now the internal structure of
Strawberry is easier to update and also easier to use programmatically, I feel
like this might lead to interesting integrations.

There's still some work to do, but this was probably the biggest the biggest
piece that we had to tackle.

With this update I found a couple of issues we had at work, we were returning
the wrong type in a couple of places and also had a few duplicated types.

Something I want to focus on next is making sure that these errors are easy to
spot and fix.

We also had to make a couple of releases to fix issues related to type hints.
MyPy is very useful, but sometimes it is hard to work with it, especially when
making plugins; hopefully things improve in future

[https://github.com/strawberry-graphql/strawberry/pull/906](https://github.com/strawberry-graphql/strawberry/pull/906)

# Optional camel-casing

The other “big” improvement is the ability to disable auto camel-casing for
fields and arguments. This was requested a while ago but I wanted to wait for
Bryce’s PR to land before doing this.

We also took the opportunity to thing how we can handle configurations; we
settled on allow users to pass a configuration parameter when creating schemas,
like so:

```python
schema = strawberry.Schema(
    Query,
    config=StrawberryConfig(auto_camel_case=False)
)
```

I really like this approach as you can have multiple schema with different
configuration without any issue.

I’m also thinking how we could use `StrawberryConfig` to disable/enable features
that could be breaking changes, so you could adopt a new version of strawberry
without having to change a lot of code, in the case we introduce a breaking
change. We’ll see how that goes :)

[https://github.com/strawberry-graphql/strawberry/pull/798](https://github.com/strawberry-graphql/strawberry/pull/798)

# Bug fixes in federation

I also found a small bug in our federation implementation and fixed it. Nothing
major, but I think we'll change how directives are printed in future so we can
decouple them from federation and also allow to have new directives that are
printed on the schema.

[https://github.com/strawberry-graphql/strawberry/pull/1068](https://github.com/strawberry-graphql/strawberry/pull/1068)

# Twitter

A few weeks ago we also opened our twitter account:
[https://twitter.com/strawberry_gql](https://twitter.com/strawberry_gql)

We will mostly use it for announcing new releases. I'm currently working on
automating the tweets when a new release is publish; currently we only have a
generic message and I'd like to get a tweet with actual information about the
release.

# Fin

Hopefully these updates are useful, they definitely keep me more motivated to
work on Strawberry and related open source projects :)

If you have questions feel free to tweet at me or join our discord channel:
[https://strawberry.rocks/discord](https://strawberry.rocks/discord)

See you next week!

---

Written at [Stones Bakery 🥯](https://stonesbakedgoods.com/).


26 July 2021


# A bit of context

At [work][1] we use Prismic to power the content of our site (at least most of
it). We are currently working on a new project that is using Apollo Federation
as our Gateway[^1].

We wanted to add the Prismic API to our Gateway, so to use only one API Jon our
frontend. Unfortunately when a GraphQL API doesn’t provide support for Apollo
Federation things aren’t as easy as specifying the service in Apollo’s services
list.

# A basic Federation example

Let’s supposed that we have one Apollo federation that’s consuming one service
for the time being.

```js
const gateway = new ApolloGateway({
  serviceList: [
    {
      name: "products",
      url: "http://localhost:4002",
    },
  ],
});

const server = new ApolloServer({ gateway });

server.listen();
```

As you can see the ApolloGateway requires a list of GraphQL services as objects
with a name and a url. This is a bit unfortunate as this means that using a
local schema doesn’t work by default.

> **Note:** we can’t use Prismic’s GraphQL API directly as they don’t provide
> the necessary fields for federation. In addition to that they also use GET
> requests instead of POST requests for the API call, and ApolloGateway always
> sends POST requests.

> **Note:** we won’t be using Prismic API in the examples of this blog post, as
> I wanted to keep the code simpler sine Prismic API needs a bit of work to
> fetch the `ref` version, which is not really useful for this example. I’ll be
> happy to provide an example repo with Prismic if it’s needed. Drop me a
> [tweet][2] in that case!

# What can we do to make this work?

So, what makes Federation work with multiple service is the Apollo Gateway,
which basically acts as glue between the services. It knows how to compose the
schemas and how to create a query plan for executing a query.

From my understanding of the source code, Apollo Gateway seems to support local
services, but, as mentioned in this [GitHub Issue][3] it doesn’t allow to
support both local and remote services at the same time by default.

Fortunately for us, we can use `buildService` to provide create a custom
DataSource for our remote schema.

> DataSource is what Apollo Gateway uses to fetch data from a service. Which
> means we can create a DataSource that proxies the requests to Prismic.

We will be using [Trevor Blades’ Countries API][4], a public GraphQL API that
doesn’t support Apollo Federation.

So, `buildService` is called for each service specified in the `serviceList`
configuration parameter for Apollo Gateway. Let’s go and update that to have a
service for the countries service:

```js
const gateway = new ApolloGateway({
  serviceList: [
    { name: "products", url: "http://localhost:4002" },
    { name: "countries", url: "http://countries" },
  ],
});

const server = new ApolloServer({ gateway });

server.listen();
```

The only caveat that we have is that we have need to provide a `url` for our
service, even it is fake.

The next step is to provide a `buildService` function, which looks like this:

```js
const gateway = new ApolloGateway({
  serviceList: [
    { name: "products", url: "http://localhost:4002" },
    { name: "countries", url: "http://countries" },
  ],

  buildService: ({ url }) => {
    if (url === "http://countries") {
      return new LocalGraphQLDataSource(getCountriesSchema());
    } else {
      return new RemoteGraphQLDataSource({
        url,
      });
    }
  },
});

const server = new ApolloServer({ gateway });

server.listen();
```

Ok, the last step is to create the function that will return the schema for the
countries service. Similar to `RemoteGraphQLDataSource` Apollo Gateway also
provides a `LocalGraphQLDataSource` which accepts a `schema` as parameter
instead of a `url`. This means that we can provide our own schema!

# GraphQL Tools

So now we know we can provide our own schema to Apollo Gateway, but how can we
proxy an existing schema? We could do this manually, but it would take a bit of
time, luckily for us there’s a package called [`graphql-tools`][5] that allows
to use a [remote schema][6] as if it were local.

In addition to that we also need to use [`graphql-transform-federation`][7] to
provide the required fields for Apollo Federation. Let’s see how our function
looks like:

```js
const executor = async ({ document, variables }) => {
  const query = print(document);
  const fetchResult = await fetch("https://countries.trevorblades.com/", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ query, variables }),
  });
  return fetchResult.json();
};

const getCountriesSchema = async () => {
  const schema = wrapSchema({
    schema: await introspectSchema(executor),
    executor,
  });

  return transformSchemaFederation(schema, {
    Query: {
      extend: true,
    },
  });
};
```

There’s a few things going on there, first we have a function called `executor`,
this is our core function that proxies the calls to the countries service. This
is not doing anything special, it is getting the document and variables and
sending them to the countries services. For Prismic we’d add headers for
authentication and change the request to be a `GET`. But the rest would be
pretty much the same.

Finally, the last piece of the puzzle, `getCountriesSchema`, which uses the
utilities from `graphql-tools` and `graphql-transform-federation` to create a
proxy schema with support for Federation.

`getCountriesSchema` uses `wrapSchema` to create a schema based on our the
Countries GraphQL API. We need to pass a schema, an executor and some optional
transforms. We are not use any transform here, but one use case is to rename the
types so they don’t conflict with other services.

Finally it calls `transformSchemaFederation` to obtain a Federation compatible
schema, the only option we are passing here is telling Federation that this
schema is extending the `Query` type, so all the fields provided here will be
composed into the federated schema. We can also pass more options here, but at
the moment we didn’t need that.

> **Note:** the code in the example is a bit broken as we are not awaiting
> `getCountriesSchema` in our `buildServices`, the final code provided in the
> [git repo has the correct solution][8], I wanted to keep the code example
> simple here.

# Conclusion

As you can see you need a little bit of code to proxy a non federated GraphQL
service with Apollo Gateway, but it is not too bad and I think it is pretty cool
that we can do this as we can move the code that deals with multiple schemas
from our clients to our gateway, simplifying how they fetch data.

Also `graphql-transform-federation` allows to specify a Federation configuration
so it is even possible to use Apollo Federation features to extend types with a
non federated service, which can definitely make the schema easier to use.

To see a fully working example of this head to the [example repo I’ve written
for this blog post][9].

> **Note:** all of this post might be deprecated in future when [project
> constellation][10] gets released to the public, which should allow federation
> of service that don’t have the (currently) required fields. In the meantime,
> feel free to try this approach.

[^1]: This is part of a bigger rewrite of our internal API, more on that in future
  blog posts hopefully.

[1]: https://team.pollen.co
[2]: https://countries.trevorblades.com/
[3]: https://github.com/apollographql/apollo-server/issues/3250
[4]: https://countries.trevorblades.com/
[5]: https://www.graphql-tools.com
[6]: https://www.graphql-tools.com/docs/remote-schemas
[7]: https://github.com/0xR/graphql-transform-federation
[8]:
  https://github.com/patrick91/apollo-federation-local-services/blob/main/server.js#L11
[9]: https://github.com/patrick91/apollo-federation-local-services
[10]: https://youtu.be/MvHzOwdLb_o


Using Apollo Federation with local schemas


# Why? 🤔

A couple of years ago when I was looking for a new job I started working on a new website, but immediately settled with a basic landing page.
  
I always wanted to have my own space on the internet, a place where I could collect all the things I like and talk about topics I love. So hopefully this pretty short blog posts is the start of that.   
  
I’ll probably write soon about Python and GraphQL, as I’m currently working on [Strawberry, a Python library for GraphQL][1]. Can’t wait to share all the updates and cool things I’ve worked on.

So, see you soon here!

[1]:	https://strawberry.rocks

patrick.wtf

Patrick
Arminio

Senior Software Engineer @ pollen.co

Latest articles:

Open-source updates 19 September 2021

Open-source updates 13 September 2021

Open-source updates 30 August 2021

Open-source updates 22 August 2021

Open-source updates 15 August 2021

Open-source updates 8 August 2021

Open-source updates 1 August 2021

Open-source updates 26 July 2021

Using Apollo Federation with local schemas

Hello there

PatrickArminio

Senior Software Engineer @ pollen.co

Latest articles:

Open-source updates 19 September 2021

Open-source updates 13 September 2021

Open-source updates 30 August 2021

Open-source updates 22 August 2021

Open-source updates 15 August 2021

Open-source updates 8 August 2021

Open-source updates 1 August 2021

Open-source updates 26 July 2021

Using Apollo Federation with local schemas

Hello there

Patrick
Arminio