Refactor so that eth-json-rpc endpoints use GraphQL to interface with Postgres #52
Labels
No Label
bug
critical
documentation
duplicate
enhancement
Epic
good first issue
help wanted
Integration tests
invalid
question
v5
wontfix
Copied from Github
Kind/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: cerc-io/ipld-eth-server#52
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Rather than interfacing directly through a pg connection
To add some context from previous discussions, and this is kind of a rough overview from a sysop perspective so there could be per service requirements that weren't taken into account, further refinement etc.
My thinking here is that
arch0-1 vulcanize geth
talks directly todb0-1 postgresql
, thendb0-1 postgraphile end points
sit in front of each database and become the central place all other database driven services talk to. Likewisearch0-1 ipld-eth-server
talks directly to vulcanize geth and all other geth dependent services talk only to the end points that ipld presents.If ipld-eth-server is itself creating postgraphile endpoints maybe that first graphql layer sitting on the db0-1 becomes redundant but I think this at least begins to paint a picture of centralizing the access paths different services take rather than having everything reaching directly to the database and geth.
Seems as though this was resolved elsewhere.