Chat Logs

  1. dreamrealfeed subcribe https://primate.run/blog.rss
  2. dreamrealfeed add https://primate.run/blog.rss
  3. nevetError: No RSS/Atom feed found at https://primate.run/blog.rss
  4. dreamrealfeed add https://primate.run/blog.rss
  5. nevetAdded feed "Primate Blog" with 20 entries
  6. dreamrealfeed subscribe https://primate.run/blog.rss
  7. nevetSubscribed to "Primate Blog"
  8. dreamrealblue: there you go
  9. bluethanks, dreamreal
  10. dreamrealblue: I was thinking of publishing the backend rest services to rest.bytecode.news, which would mean that I could actually handle github updates live instead of polling for them
  11. dreamrealand that would give UIs a consistent thing to hit, but it means that I need to harden some aspects of the services while I'm at it
  12. blueI'm... not sure why that is the case; because you can't do it without a universally reachable url?
  13. blueanyway don't call it REST: call it api, would be my call. rest exposes the technically implementation, which is irrelevant
  14. dreamrealtrue enough
  15. dreamrealbut what do you mean: why is that not the case for... what?
  16. dreamrealif we have api.bytecode.news, github can indeed post updates to a consistent URL
  17. dreamrealand then we can stop polling github for updates
  18. blueyes that was my point. if you don't 'expose' the backend in some universally reachable way, you can only do polling
  19. dreamrealI feel like we're saying the same things but different
  20. blueyes
  21. dreamrealso let's reset: my thought is, get api.bytecode.news online ASAP. Since it allows anonymous posts to the content, that means we need to make sure that *write* operations are constrained where possible and have *limits* where constraints aren't possible, like content posting
  22. bluedreamreal: idea; if you have api.bytecode.news, then... other subdomains feel a bit overengineered. I'm truly questioning the usefulness of primate/nextjs here vs just a frontend
  23. bluewhy the indirection? what's the value?
  24. dreamrealblue: https://enigmastation.com/2014/07/09/repost-some-of-what-id-wanted-to-do-for-theserverside/ is the mindset I had
  25. dreamrealIgnore the JCR bit, JCR is great but effectively dead and gone
  26. dreamreal(not really, but it's a lot for the value it would provide here)
  27. blueyeah I'm down to frotnends now
  28. blueI read REALLY fast -- faster than you :P
  29. dreamrealit's not a race, newsom
  30. blueyeah the problem still remains the indirection. a react.bytecode.news might make sense... I'm not sure nextjs/primate
  31. dreamrealmy thought was that most users would use bytecode.news or www.bytecode.news
  32. dreamrealso whatever fulfilled the interface requirements best would be that
  33. blueI understand that. I'm just still convinced about having two backends, especially if you have api.bytecode.news
  34. bluenot convinced*
  35. bluebut maybe.. hm.
  36. dreamrealYeah... I ... don't know what the "other backends" would be
  37. dreamrealThere's a design question here I'm not qualified to answer
  38. blueso there's a real tension here, and the tension is there. normal web app applications typically don't use APIs, at least directly
  39. bluethey use bespoke paths, which might or might not compose over APIs
  40. blueyou follow?
  41. blueapi.bytecode.news is interestingly not for a web app... but for someone writing clients for nevet
  42. blueinteresting*
  43. blueof course, a web app COULD use it. but it would typically also access a DB in a more direct fashion
  44. bluethings like transactions... are harder to realise if you have a backend solely relying on an API
  45. dreamrealI mean... this is just AJAX stuff
  46. dreamrealI'm saying that front ends would use AJAX to hit the api
  47. blueI realise this is ajax stuff. but say I want to have a route bunlding SEVERAL API calls in one. how do I transactionalise this?
  48. dreamrealAdmittedly I'm probably BADLY out of date...
  49. dreamrealI don't know! But the API endpoints were designed to BE transactional endpoints - you wouldn't normally WANT to bundle them separately
  50. bluein which case, an extra backend such as nextjs/primate is an indirection layer with zero added value
  51. dreamrealunless the front end NEEDED it, I suppose, gut ... again, this is not my area of expertise at all
  52. dreamrealI had to look up the term AJAX to remember it!
  53. blueyeah, we don't use that anymore. just REST/JSON
  54. bluebut let me give you an example
  55. dreamrealsure
  56. blueDELETE /admin/comments/{id}
  57. dreamrealokay?
  58. bluesay the frontend has the ability to select several comments for deletion. the primate route would get the ids. what does it do now?
  59. bluein a normal application, this would be transactionalised
  60. bluenow you COULD say, I'll just create another endpoint where you can delete several comments at once, fair
  61. bluebut there are other cases that are less straightforward
  62. dreamrealah. Right. Okay, I'd say that THAT BEHAVIOR is actually out of spec. And if behavior like that SHOULD BE in spec, we need to create a backend endpoint for it. That's part of why I want to get the API public and out there as soon as possible.
  63. blueI guess the point I'm trying to make is... building web apps on top of APIs is possible, but typically, you do need transactions to give you the bespoke abstraction level that isn't available over API call composition
  64. blue"I want to delete the comments but also inform the user about it, and I want it as a binary operation -- either everything or nothing"
  65. dreamrealyeah, well, I've been trying to design the API such that the response to that is "cool story bro the API is right there." And the other thing about nevet is that it's VERY literally designed on a messaging platform: you could, in fact, connect to the underlying mechanisms if you had access and do EXACTLY THAT.
  66. dreamrealThe API isn't designed to be composed; it's designed to be "these are the things you can do," not elements of transactions *but transactions*.
  67. blueyeah I understand
  68. bluethat however, makes frontends very rigid
  69. blueand maybe that's intended
  70. dreamrealit is, for better or for worse
  71. bluebut frontends aren't supposed to transport API/backend logic 1:1
  72. dreamrealwell, there are different design philosophies, and tradeoffs are definitely involved
  73. dreamrealI didn't want the ability of a front end to work to depend on how well a given developer could compose operations
  74. dreamrealthe operations work or they don't, so the front end's "works or not" is based on whether it interacts with those sets of operations
  75. blueso from this perspective, I *think* having a secondary backend is totally an overkill
  76. bluethat is: rather than using primate, I would be taking your reference and rewriting it in svelte or react
  77. dreamrealthe front end, in the end, is an ingress/egress adapter itself: the controllers *quite literally* translate the HTTP data into operational types, and these get fed into the event system, *just like* IRC strings do, discord, slack. It's all the same engine. the factoid operations work over HTTP just like they do IRC - it's *very* literally the same code, there's not an HttpFactoidOperation, just a
  78. dreamrealGetFactoidOperation that knows how to translate strings into factoid requests (for stringly communications) and how to respond to factoid requests
  79. dreamreal*nod*
  80. bluebut also, this might result on having to reiterate on the API quite a lot; see comments example: if you want to be able to delete several comments, sending n API calls is a nightmare
  81. blueresult in*
  82. blueany composed operation in the frontend that has no API correspondence... would trigger either "no, you can't do that" or "wait, I need to add this to the API"
  83. blueI'm telling you from experience this COULD become rather unpleasant
  84. bluedifferent proposition:
  85. dreamrealOh, you're not wrong, at all. But again, this is why I was trying to involve people with UI experience early and often, and I even said "please give me feedback" because we expect the surface to mutate until it fits the needs well
  86. bluethe primate backend is a FULL-STACK app *using* nevet. in which case, it has its own database. but there might be a lot of data repetition involved
  87. blueso the primate backend/app can compose however much it wants, using nevet API primitives
  88. dreamreal*nod* And I'd say that as a strategy, that could *work* but would be suboptimal - a front end should NEVER EVER talk to nevet's database, because the fact that nevet uses postgresql is *incidental*. I could easily swap it for an IMDG (and as soon as I convince gigaspaces to give me a license, you better believe I'm doing it) or mongodb.
  89. blueit's more than that. primate would enterain its own db, completely separated from nevet's pgsl
  90. blueentertain*
  91. dreamrealif it did so, that'd be fine. I wouldn't care.
  92. dreamrealThe key is that they'd be SEPARATE systems, and the system of record would be nevet.
  93. bluebut I'm not a super huge fan of data duplication
  94. dreamreal(I used to work for gigaspaces; nati shalom is a good friend.)
  95. dreamrealSo is gil tene, actually
  96. blue.ils?
  97. bluethey do sound like it
  98. dreamrealaye
  99. bluemaybe the golden path is the primate app acting as a sort of medial cache here
  100. dreamreal... for primate, sure
  101. bluefor data
  102. dreamrealLike I said, my goal was to provide the system of record and the API as a baseline; how it's used isn't important to me AS LONG AS nevet remains the system of record
  103. blueI'd need to think how to make that works, but things like posts/comments would be cached
  104. bluework*
  105. bluedeleting them.. well, there it becomes hard because you need the source of truth for that
  106. blueso for example
  107. dreamrealWell, primate could do that as a transaction: cascade each one as an op through nevet in order. failures would radiate outward depending on what they were (not found isn't the same as "could not delete.") But if the API *needs* a "delete multiple things" then maybe that's a need that gets addressed.
  108. blue`GET /posts/search` this could be well cached by the primate database, with periodic resync
  109. dreamrealI'd think search would be one of those things caching would serve LEAST, but eh
  110. dreamrealthe way I see it, primate's local DB would be a cache of *actual known data* - like, hit a slug, that's a known thing, you can cache that (and hope it doesn't get updated after caching).
  111. bluewell, consider this
  112. bluefor me as an app developer, doing this is ideal: `const posts = await Post.find({ where: ... });`
  113. bluethis is typically a primate ORM query
  114. blueI can build an interface around it, with querying for certain aspects for a post, limiting, criteria, etc.
  115. bluenow, one things I've been working on which would be already beneficial is the generation of the openapi client
  116. bluein which case, I'd already have at least a client that can do API calls, as documented
  117. blueso if the operation id is searchPosts, it'd be `client.searchPosts` instead
  118. bluethis call, however, is EXPENSIVE. it's an API call
  119. blueit's possibly also not very flexible, so maybe doing a GET posts periodically instead, and caching it in my own db, is faster
  120. phalethdoes that call enforce pagination?
  121. dreamrealin the openapi call, yes
  122. bluethere is a `page` param, yes
  123. bluein both GET posts and GET posts/search
  124. phaleththen can put max limit to the page size in order to not make it expensive
  125. bluethe expensive part is the extra web request
  126. bluethat means every primate frontend<>backend request is essentially two web requests
  127. phalethwell, that's the problem of the web
  128. bluealso, if I ever wanted to stream posts... or dynamically update the page..
  129. phalethprovide bson API or some sort of gRPC, but that's all you can do
  130. phalethcause there are two big problems in programming, and you can avoid the second one: cache invalidation problem
  131. blueyeah I thought of gRPC or json rpc, but currently nevet is a simple JSON api, and there's charm in that simplicaition
  132. blueand yes, cache invalidation is an absolute dumpster fire catastrophe, I 100% agree
  133. bluebut I'm worried about performance, perhaps prematurely here
  134. bluemy mind says: "if there's an API, and the API is all the composition we get, why not query it directly then? what's the use for a primate backend?"
  135. bluejust issue `fetch` directly to api.bytecode.news and be done with it. no real need for primate
  136. phalethin any case we can always employ memcached or something like that but only when that starts making any sense, but I'd not worry even if there's traffic already
  137. phalethof which there is currently none
  138. blueya
  139. dreamrealew
  140. dreamrealmemcached
  141. dreamrealew
  142. bluemaybe I'm chasing imaginary ghosts
  143. dreamrealew
  144. dreamrealmemcached--
  145. nevetmemcached now has karma of -1.
  146. dreamrealwhat a POS
  147. dreamrealmemcached--
  148. nevetmemcached now has karma of -2.
  149. bluebut APIs aren't built for performance... they're built for inter-app communication
  150. phalethfor sure one can shoot themselves in the foot with memcached, but again avoid the second big problem of programming if possible
  151. blueyou didn't stay the first one
  152. phalethwhat you can do is make the application layer scalable by not storing sessions server side
  153. bluestate*
  154. phaletheh
  155. phalethof course it's naming, can't solve that one
  156. blueah. thought you'd say rust
  157. blue:P
  158. phalethheh
  159. bluewhich btw
  160. blueew
  161. bluerust
  162. blueew
  163. blueew
  164. bluerust--
  165. nevetrust now has karma of -1.
  166. bluewhat a PON
  167. bluerust--
  168. nevetrust now has karma of -2.
  169. bluedone!
  170. dreamrealkarma chronos
  171. nevetchronos has karma of 3.
  172. dreamrealnevet's karma database still isn't old enough to decay yet :D
  173. bluetrue
  174. dreamrealkarma decays so "old karma" affects you less than new karma
  175. bluerust--
  176. nevetrust now has karma of -3.
  177. blue*patpat* good boy nevet
  178. dreamrealnevet is in the "ignore list" for karma automatically, too :D
  179. bluephaleth: dreamreal had a cool suggestion earlier: https://github.com/primate-run/primate/issues/250
  180. nevetSupport for HEAD · Issue #250 · primate-run/primate
  181. bluewhich I'm probably gonna add to .37
  182. blueas an opt-in config option: http.autoHead: p.boolean.default(false)
  183. blueoh man I HATE camelcase
  184. phalethyeah, web is broken when services respond with 404 on HEAD requests
  185. blue16:45 < phaleth> of course it's naming, can't solve that one
  186. blue+1
  187. blueI need to update the config page
  188. bluehttps://primate.run/docs/configuration
  189. bluehttps://github.com/primate-run/primate/blob/master/packages/core/src/private/config/schema.ts
  190. bluethose aren't synced
  191. blueyou know what, maybe I should just add jsdocs atop that and general that page automatically
  192. bluegenerate*
  193. bluebecause I know I will never remember to update the docs whenever I add or remove a config option
  194. phalethyeah, clankers are getting confused now
  195. bluethis is another case against ai, true
  196. blueemergent technology is practically useless
  197. blueso everyone just regenerates old, outdated code
  198. phalethwith the same old bugs
  199. bluewe had it earlier with nevet, I was querying it for an HTTP RFC, it gave me an old, obsolete one instead of the newer one
  200. blueit's almost like AI hinders progress
  201. blueit will give you reliable info about express, but garbage about primate
  202. phalethAI straight up hinders progress
  203. bluedreamreal: how far are we from nevet informing us here in the channel about issues, issue comments, PRs, commits and commit comments occuring on GH?
  204. dreamrealif it can poll, about two minutes
  205. dreamrealyeah, webhooks needs the api.bytecode.news
  206. blueok, I'll wait for that then
  207. bluethose can be reliably tested, btw
  208. bluein the webhook conf screen ongh
  209. blueon gh*
  210. bluethere's like a test event
  211. bluedreamreal: https://github.com/terrablue/gpbot/blob/master/routes/index.js
  212. blueif you need reference, here is how gpbot used to do it. I only added the events I was interested in
  213. phalethlast night at the exact same moment 47.7 clankers have been misled https://images4.imagebam.com/2e/60/e5/ME1AZ46G_o.png
  214. bluewhich was release, issues, push, commit_comment and ping
  215. bluephaleth: LOL
  216. bluehttps://github.com/terrablue/gpbot/blob/master/routes/index.js#L25-L27
  217. blueI do believe that htia function can be replaced by https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Uint8Array/fromHex today
  218. nevetUint8Array.fromHex() - JavaScript | MDN
  219. bluewhich is so nice!
  220. bluedreamreal: java equivalent: byte[] bytes = HexFormat.of().parseHex("CAFED00D");
  221. blue(need `import java.util.HexFormat`)
  222. phalethnot too sure I ran the right command https://images4.imagebam.com/de/91/9f/ME1AZ705_o.png
  223. bot<discord:blue> Looks good
  224. bot<discord:blue> But you can also drop the mvnw nonsense and use maven directly
  225. phalethmaven: not found
  226. bot<discord:josephbottinger> mvn and mvnw
  227. phalethmvn: not found
  228. bluephaleth: https://gitea.repopack.app/jottinger/bytecode.news/commit/3162d8ed1ae5d7d789b7005468e144bc44f3cb87
  229. bluedreamreal: fyi https://github.com/terrablue/bytecode.news/commit/3162d8ed1ae5d7d789b7005468e144bc44f3cb87
  230. bluephaleth: I'll move that jottinger org to `blue`, on gitea, if you don't mind
  231. blueit would be nice if you could include this primate app in your deployment, and it would be able to reach the nevet backend
  232. blueso three nspawn machines: pgsl, nevet, and primate
  233. bluethe only one that needs exposure to the world is the primate one
  234. blueis this possible?
  235. blueregarding mvn, you need an image that contains mave
  236. bluemaven*
  237. bluephaleth: https://dpaste.com/GWFBVPGA3
  238. phalethyeah, trying to make it work with the zip first
  239. blue`maven:3.9.12-eclipse-temurin-25`
  240. phalethdpaste.com blocks my proxy, but don't worry, it builds
  241. bluedreamreal: the most relevant part of that integration is the otp/request route: https://github.com/terrablue/bytecode.news/blob/master/apps/primate/routes/otp/request.ts
  242. blueit takes JSON from the frontend, verifies it's an email, then sends it to nevet
  243. bluemost of this is boilerplating that will later be replaced by the opencpi client
  244. blueso: client.verifyOtp({ email })
  245. blueshould replace https://github.com/terrablue/bytecode.news/blob/master/apps/primate/routes/otp/request.ts#L15-L23
  246. blue... and this probably shouldn't be a GET route
  247. blueanyway, I just need something for phaleth to work with. once we have that threeway setup, I can get productive with it!
  248. blueexpect... greatness!
  249. phalethturns out nevet runs on postgres 18.3 https://upaste.de/raw/5gH
  250. bluevery nice
  251. phalethyeah, it keeps crashing
  252. bluelol
  253. bluephaleth: https://gitea.repopack.app/blue/bytecode.news/
  254. phalethactually, the connection failed, so I
  255. phalethI'll try postgres 17.9 tomorrow
  256. blueok
  257. phalethgotta go now
  258. blueciao
  259. phalethbye
  260. bluedreamreal: https://github.com/primate-run/primate/issues/251
  261. nevetProposal: Add `AppFacade#env(key: string)` · Issue #251 · primate-run/primate
  262. bluechovy: I believe automatic env loading is also something you have expressed interest in in the past
  263. bluejreicher: if you feel like commenting this, you're welcome! https://github.com/primate-run/primate/issues/251
  264. nevetProposal: Add `AppFacade#env(key: string)` · Issue #251 · primate-run/primate