rockerest’s avatarrockerest’s Twitter Archive—№ 19,297

  1. …in reply to @mmcclannahan
    mmcclannahan I've found that early (pre-code) research followed by targeted development is best. It results in minimal API surface area targeted at behavior instead of structure. E.g. define what you need to do for clients and expose those as callable procedures
    On twitter.com Twitter logo rockerest’s avatar 2022 Mar 31 Mood +2 🙂
    1. …in reply to @rockerest
      mmcclannahan Versus exposing your database as endpoints and trying to fix how messed up that is after the fact (e.g. why GraphQL exists).
      Permalink On twitter.com Twitter logo rockerest’s avatar ❤️ 1 Favorite 2022 Mar 31 Mood -3 🙁
      1. …in reply to @rockerest
        mmcclannahan I'm not 100% on the ultimate scalability, but a pure websocket client connection architecture that just sends messages requesting procedures to run (and the results to come back) is really appealing to me.
        Permalink On twitter.com Twitter logo rockerest’s avatar ❤️ 1 Favorite 2022 Mar 31 Mood +3 🙂
        1. …in reply to @rockerest
          mmcclannahan The key to all of this is: your API should NOT reflect your data model. It's totally fine (preferable?) to expose explicit actions that business logic can handle OUTSIDE of (behind) the API.
          Permalink On twitter.com Twitter logo rockerest’s avatar ❤️ 1 Favorite 2022 Mar 31 Mood +1 🙂
          1. …in reply to @rockerest
            mmcclannahan This is the crux of my complaints: there are so many solutions bent in making it easier to interface with the data model instead of understanding that data modeling is an implementation detail of business logic. The API is free to have an entirely different surface area.
            Permalink On twitter.com Twitter logo rockerest’s avatar ❤️ 2 Favorites 2022 Mar 31 Mood 0
            1. …in reply to @rockerest
              mmcclannahan Having a separate structure in the API (e.g. explicit behavior-based RPC) is preferable to exposing your data model. It's an INTERFACE, after all.
              Permalink On twitter.com Twitter logo rockerest’s avatar ❤️ 1 Favorite 2022 Mar 31 Mood -1 🙁
              1. …in reply to @rockerest
                mmcclannahan Happy to walk you through some personal examples in code later so you can broadly get an idea. But the general idea is everything is handled outside the API because the API is just an interface to more complex code that I might want to reuse NOT in a web API.
                Permalink On twitter.com Twitter logo rockerest’s avatar ❤️ 1 Favorite 2022 Mar 31 Mood +4 🙂
                1. …in reply to @rockerest
                  mmcclannahan By the way, I think a lot of API design springs from "what if this doesn't work later, we should make it as generic as possible." And the reality is that it never works later no matter how generic it is, and you constantly need patches and hacks.
                  Permalink On twitter.com Twitter logo rockerest’s avatar ❤️ 1 Favorite 2022 Mar 31 Mood 0
                  1. …in reply to @rockerest
                    mmcclannahan Instead, the theory should be "let's build EXACTLY what we need now (RPC)" and then we can freely expand or update as necessary, while matching exactly our consumers' use cases. The primary requirement here is prior research and data modeling.
                    Permalink On twitter.com Twitter logo rockerest’s avatar ❤️ 1 Favorite 2022 Mar 31 Mood +1 🙂