durkes

Example config:

const domainToPort = { 'localhost:3000': 3001, 'example.com': 3002, 'api.example.com': 3003, };

I wonder if you remind it with those instructions with each prompt, if that would help? Also, I'm curious, approx how much does it cost for each small app build / iteration?

This is really cool. I had a lot of fun building a hangman style game just now! It took 3 prompts to get it right... here was my third iteration (sorry, didn't save the first two): There is a problem where player 1 is unable to enter the secret word at the very beginning. Fix this issue. Also, clear the letter from the input after each time player 2 makes a guess, but display the incorrect guesses somewhere and don't allow player 2 to guess the same letter more than once.

I think it got a little confused with my last prompt: "Make both players also able to submit the input with the enter key." It correctly added the functionality, but it left it's explanation in the HTML of the page too. Still very cool. Here is the working game: https://backend-pico.onrender.com/hyundai-interface

It seems risky to be storing sensitive information including passwords. How are you protecting this data?

This worked for me. Thanks!

Somewhat off topic, but I'm getting a lot of network errors lately. Has anyone else noticed an increase? I'm also curious if any Plus users here can share their experience...

Cool and fun app! Without knowing much about the GPT3 API, I'm curious if you had to provide training data for each character, or if it's simply a setting on the API

There isn't any exponential backoff built-in, just the 500ms timeout in between fails. You can, however, set the number of retries to something you want your app to tolerate and then if it still fails, handle the error accordingly to pager duty or your own custom logic, etc.

Example w/ retries config: https://github.com/durkes/wubsub/blob/main/examples/client.j...

Regarding the backpressure for messages that the client is trying to publish while not connected, they will each be held in a setTimeout recursively until successful trying every 500ms also. If you build in your own custom receipt logic, this could be avoided. I considered building this in but wanted to keep it simple. Open to suggestions.

It's coded to retry connecting every 500ms. Usually the connection will have to timeout first, so it takes longer for each retry. I set my retries to Infinity.

Messages that the client publishes while trying to connect are pending also every 500ms to try to resend as soon as it connects. This might be something that should be customizable to return an error or retry in a future version.

Because this design is send and forget / fire and forget (similar to redis), messages published when a client is not connected will not make it to that client. If receipt confirmations are needed, it would need to be coded into the app using pubsub.

Thanks for the reply! I will get this info added to the docs soon.

I appreciate that. I used redis in the past, but wanted a node-only solution to keep things simple.