Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Building APIs with GRPC, PHP, and Golang

Cecy C.
June 02, 2018

Building APIs with GRPC, PHP, and Golang

How to use GRPC, Protobufs, PHP (and a bit of Golang) to build APIs and microservices.

Cecy C.

June 02, 2018
Tweet

More Decks by Cecy C.

Other Decks in Technology

Transcript

  1. The “RPC” part stands for “remote procedure call,” and it’s

    essentially the same as calling a function in JavaScript, PHP, Python and so on, taking a method name and arguments. Source: Smashing Magazine
  2. Why gRPC? • Use HTTP/2 • Language agnostic • Highly

    efficient / scalable • Handle large amounts of data
  3. Who is using it? • Google • Netflix • Docker

    • Square • CoreOS • Twitch (Twirp)
  4. What you will need • Protocol Buffers to define your

    service • Protoc to generate client and server stubs based on your service definition • gRPC server to handle requests
  5. Install (Mac OS) • brew install grpc • brew install

    protobuf • brew install protoc • brew install golang go to grpc.io for other alternatives
  6. project-dir ├── client | └── client.php ├── proto | └──

    service.proto ├── server | └── server.go|js|rb|py ... └── libs └── ruby └── python └── ...
  7. *Note: you will need to install some stuff to get

    started in PHP • composer install grpc as a dependency • pecl install grpc / protobuf • Full instructions on getting started: https://grpc.io/docs/quickstart/php.html
  8. Pain points • Legacy codebase (~10 years old) • Monolith

    codebase • Heavily coupled == hard to unit test • Scaling problems
  9. How gRPC helped • Replace small pieces of functionality with

    microservices • Easy to do by “resource”
  10. From REST to microservice GET /discovery Discovery service GET /user/:id/contacts

    Contacts service GET | POST /user/:id/webhooks Webhooks service GET | POST /webhooks GET /user/:id/messages Messages services GET /user/:id/folders Folder service
  11. This solves... • Feature parity between REST API and client

    libraries / wrappers • Feature parity between API and docs • Lack of knowledge in the team around certain languages • Easy for other teams to consume your service