Since people can't connect to it from IronWorker, let's have a list of alternatives and point people to this page whenever someone asks about it.
Public chat convo:
Before I dive too deep, I'm looking to replace Delayed::Job with IronWorker on Heroku, primarily because of throttling.
Does IronWorker have access to the full Rails environment for my app?
That is, can I do DB stuff just like normal?
(in the workers)
2) no access to shared heroku DB
1) rails env is limited significantly, we're encouraging people to pass stuff they want as payload
2) this is Heroku hosting limitation
What about a dedicated DB?
will work fine, as you'll allow access from outside world
we do not limit anything, really
it's heroku who limits access to shared dbs
Makes sense. Thanks, that info helps.
@treeder I'm not sure where we'd put this. I can see what it'd say:
"If you need hosted database storage, we've gathered a few examples for you:
But I don't know where in dev we'd put this. Any thoughts on that? I'd like to not have a dedicated page about databases, because there's really not that much to say. The things that would be crammed into that article are better suited in other places (e.g., instead of writing a database page, I'd rather have a page about interacting with other services--using max_concurrency, delays, handling failures in the outside services... etc.)
Maybe on that outside services page, we could have a short list of database providers?
This may not apply anymore now that Heroku migrated everyone to their postgres service. I believe that's open ya?
No idea. Will find out.
I think we need something about databases in there. Mostly just to answer questions that come up or give people some idea as to whether they're on the right track.
Maybe we use stackoverflow to hold a lot of questions but then we need some jumping off point / list / search box for people to go there.
@frommww I think those things apply to 3rd party APIs and other things outside our environment, too, though. I'm not saying I don't think we should address them, I think we should just kind of be generic about it. I have no issue with using databases as an example, but I'd like the page to apply to more than just databases, because the paradigm and strategies are the same. Something like "Working With Your API, Database, and Other Services" or something.
Paddy can you outline the page before writing the content? I'm leaning with Ken that connecting with databases is so fundamental that it needs its own section but I could go either way.
Sure. Right now, our focus is on the docs for the partners and on improving the overall hygiene of the Dev Center (pruning old pages, etc.), so it will probably be the end of the week or next week before I start mapping this article out.
I could be entirely wrong, and as I start mapping the article out, databases stand out and don't fit in enough that it makes sense to include them. In which case, let's figure out where they make sense. But my gut feeling is that the content for them and APIs will be 99% identical. I'll keep you both apprised, and share mindmaps and drafts with you as I go.
Would it be possible unassign me from this issue, or close the issue?