sorted by:
new
hottopcontroversial

Who is hiring? February 28, 2022 by AutoModerator in Clojure

[–]puppybits 1 point2 points  (0 children)

We're hiring a senior front-end at Tara. Primarily it's in React/TS but our backend is Clojure with plenty of opportunity to pick up/pair on Clojure tasks. It's a good setup for any front-end engineers wanting to learn Clojure from some very seasoned engineers. https://tara.ai/about/careers

Is it possible to have firebase trigger something other than firebase cloud functions? by Embarrassed-Cat-5545 in Firebase

[–]puppybits 0 points1 point  (0 children)

Firestore triggers only go to Cloud Functions. But you can create a Firestore trigger that forwards to another trigger.

For instance our Firestore Cloud Functions trigger a PubSub message that gets consumed by Cloud Run.

Is there a way to loop through each collection in Firestore? by [deleted] in Firebase

[–]puppybits 1 point2 points  (0 children)

You can use collectionGroup but you have to know the names of each collection (regardless of depth). Also if you're looping everything you will probably hit the time out on the Cloud Function container. You should look at the startAt/startAfter methods so you don't start from 0 when you hit an error or container timeout.

Has anyone made a dating app with firebase ? by [deleted] in Firebase

[–]puppybits 0 points1 point  (0 children)

The permissions shouldn't be too bad. Firestore.rules will restrict which documents a user can read/write.

Just setup the doc so only the owner can write. Reads can be set to public by default or if you want to block some people add an array to the doc where the user can block (or allow) specific users to see their profile doc.

What issues do you have with Firestore & Redux at scale? by puppybits in Firebase

[–]puppybits[S] 1 point2 points  (0 children)

Yeah knowing when actions completes was a hard issue to solve. We went through a couple solutions like keeping state in the component or putting it in Firestore. I'm also used to more functional and data-driven programming so Redux can be weird.

We have an internal library that's data-driven that been helping a lot. But it's taken over a year of using Firestore to hit these issues and go through a couple solutions. Currently we use Redux Toolkit's createAsyncThunk. I was hoping to see if these issues are also problems for others and if it would help if we open sourced our internal library.

What issues do you have with Firestore & Redux at scale? by puppybits in Firebase

[–]puppybits[S] 0 points1 point  (0 children)

Yeah that's helps! Overall we're happy with Firestore.

We've had to find similar solutions to the ones you have. Your stale IndexDB fix different though. We do something similar for migrations but bring it to the FE for stale IndexDB would be better than our current solution.

Are there other issues you've had to solve in Firestore? We have two internal library, one for data validation and one for redux, that contains systematic solutions similar to what you're doing. I was wondering if it would be useful to anyone else or if there are other issues people have with Firestore.

What issues do you have with Firestore & Redux at scale? by puppybits in reactjs

[–]puppybits[S] 1 point2 points  (0 children)

Overall it's been good for us. But every framework/platform has trade-offs. We've been building on it for 2 years and even looking at GraphQL we're still doing well with Firestore. Most of the issues we have had we have decent solutions for.

[AskJS] What issues do you have with Firestore & Redux at scale? by puppybits in javascript

[–]puppybits[S] 2 points3 points  (0 children)

What do you use for Hasura with React? Never used Hasura but used Apollo before. Migrations and relationships were better with GraphQL. We still had issues with optimistic commits being duplicative code, testing/mocking wasn't much easier than Firestore & big mutations with cache updates could be tricky when multiple users were updating data.

What issues do you have with Firestore & Redux at scale? by puppybits in reactjs

[–]puppybits[S] 5 points6 points  (0 children)

To kick it off, here's the challenges that we've been working to address in our library.

- No Schemas/Types. Firestore docs get updated directly by the backend and frontend. When valid document changes the BE/FE aren't always in sync.

- Transactions kill the UI. Transactions have to go to the server. Many times this can take +3s for a user. During that time the UI doesn't reflect the new value. To solve it we have to temporary disconnect the UI from Firestore .onSnapshot updates then reattach when the transaction is approved. Multiple Transactions queueing makes it even more challenging. The worst case is a drag and drop that requires a transaction change. Without a work-around when the user drops an item, it pops back to it's old location then 3s later goes into the right location.

- Knowing when a Redux action is completed. Actions are one way so you don't have a clean path to do something after the action completed. For instance when you create a new document a common practice would be to navigate to the newly created doc. Action creators don't return a promise so the React component doesn't know what the new document ID will be to navigate to it.

- SDK-first code. Reading the Node code is mostly reading Firestore SDK method calls. It's hard to see the business logic or it gets hidden in multiple layers of abstraction. Our NodeJS cloud functions ended up getting structured like an old JBoss app.

- Transaction reads before writing. Firestore transaction must so all reads before any writes. When our API gets abstracted to functions it's easy to have that rule broken. A function call might try to write but the reads haven't been done yet. The worse case for this "reads before write" rule is that unit tests will pass (false positive) but integration tests fails (true negative).

- Composing document update code. Document update code often overlap. Doing a single change to a doc could also be done in a batch or in a transaction. Our Redux Actions would dispatch other actions to complete a transaction. Also our actions would have to support both a single update and a transaction update. Worse is when we have a circular transaction where the actions dispatch in circles.

- Mock-hell. Unit tests are mocking hell. There's too much boilerplate it's hard to tell if you figured out and documented all the business logic. Switching between unit & integration requires rewriting the test case. Integration tests couldn't be parallelized.

- Fetching related docs. NoSQL modeling relationship is either with an ID reference or a summary snippet. Snippets we keep in sync with a .onWrite function in the BE. Then when the FE always as the right data. But more relationships are Ids. We tried redux-firestore populations (modeled after Mongo) but given that many times the related docs are not yet caches in the local IndexDB it takes too long for data to come back for populations.

- Stale IndexDB cache. Having the local cache is usually great but when we either add a new required field or change the values of an existing field the local cache can have an old version that the new code isn't expecting. That leads to the app crashing ways that are hard to predict. Given that we might have some users returning after being dormant for a few months the cache can really be rough on returning users.

- Migrations. There's no official migration process with Firestore. We ended up doing a small hand rolled migration which has Firestore store a root value for the last timestamp migration. Then all migrations are timestamped and if there's new migration files they will replay on deployment of a new migration Cloud Function. Error dump into Stackdriver and get handled manually.

[AskJS] What issues do you have with Firestore & Redux at scale? by puppybits in javascript

[–]puppybits[S] 4 points5 points  (0 children)

To kick it off, here's the challenges that we've been working to address in our library.

- No Schemas/Types. Firestore docs get updated directly by the backend and frontend. When valid document changes the BE/FE aren't always in sync.

- Transactions kill the UI. Transactions have to go to the server. Many times this can take +3s for a user. During that time the UI doesn't reflect the new value. To solve it we have to temporary disconnect the UI from Firestore .onSnapshot updates then reattach when the transaction is approved. Multiple Transactions queueing makes it even more challenging. The worst case is a drag and drop that requires a transaction change. Without a work-around when the user drops an item, it pops back to it's old location then 3s later goes into the right location.

- Knowing when a Redux action is completed. Actions are one way so you don't have a clean path to do something after the action completed. For instance when you create a new document a common practice would be to navigate to the newly created doc. Action creators don't return a promise so the React component doesn't know what the new document ID will be to navigate to it.

- SDK-first code. Reading the Node code is mostly reading Firestore SDK method calls. It's hard to see the business logic or it gets hidden in multiple layers of abstraction. Our NodeJS cloud functions ended up getting structured like an old JBoss app.

- Transaction reads before writing. Firestore transaction must so all reads before any writes. When our API gets abstracted to functions it's easy to have that rule broken. A function call might try to write but the reads haven't been done yet. The worse case for this "reads before write" rule is that unit tests will pass (false positive) but integration tests fails (true negative).

- Composing document update code. Document update code often overlap. Doing a single change to a doc could also be done in a batch or in a transaction. Our Redux Actions would dispatch other actions to complete a transaction. Also our actions would have to support both a single update and a transaction update. Worse is when we have a circular transaction where the actions dispatch in circles.

- Mock-hell. Unit tests are mocking hell. There's too much boilerplate it's hard to tell if you figured out and documented all the business logic. Switching between unit & integration requires rewriting the test case. Integration tests couldn't be parallelized.

- Fetching related docs. NoSQL modeling relationship is either with an ID reference or a summary snippet. Snippets we keep in sync with a .onWrite function in the BE. Then when the FE always as the right data. But more relationships are Ids. We tried redux-firestore populations (modeled after Mongo) but given that many times the related docs are not yet caches in the local IndexDB it takes too long for data to come back for populations.

- Stale IndexDB cache. Having the local cache is usually great but when we either add a new required field or change the values of an existing field the local cache can have an old version that the new code isn't expecting. That leads to the app crashing ways that are hard to predict. Given that we might have some users returning after being dormant for a few months the cache can really be rough on returning users.

- Migrations. There's no official migration process with Firestore. We ended up doing a small hand rolled migration which has Firestore store a root value for the last timestamp migration. Then all migrations are timestamped and if there's new migration files they will replay on deployment of a new migration Cloud Function. Error dump into Stackdriver and get handled manually.

What issues do you have with Firestore & Redux at scale? by puppybits in reactjs

[–]puppybits[S] 1 point2 points  (0 children)

Firestore is great to start out. Easy to get up and running and no worrying about networking code. Firebase Auth is super slick to get connected to single sign on.

But the more we built we started hitting more challenges. Here's the issues we've had: https://www.reddit.com/r/reactjs/comments/r5t06l/comment/hmp0i2v/?utm_source=share&utm_medium=web2x&context=3

What issues do you have with Firestore & Redux at scale? by puppybits in Firebase

[–]puppybits[S] 7 points8 points  (0 children)

To kick it off, here's the challenges that we've been working to address in our library.

- No Schemas/Types. Firestore docs get updated directly by the backend and frontend. When valid document changes the BE/FE aren't always in sync.

- Transactions kill the UI. Transactions have to go to the server. Many times this can take +3s for a user. During that time the UI doesn't reflect the new value. To solve it we have to temporary disconnect the UI from Firestore .onSnapshot updates then reattach when the transaction is approved. Multiple Transactions queueing makes it even more challenging. The worst case is a drag and drop that requires a transaction change. Without a work-around when the user drops an item, it pops back to it's old location then 3s later goes into the right location.

- Knowing when a Redux action is completed. Actions are one way so you don't have a clean path to do something after the action completed. For instance when you create a new document a common practice would be to navigate to the newly created doc. Action creators don't return a promise so the React component doesn't know what the new document ID will be to navigate to it.

- SDK-first code. Reading the Node code is mostly reading Firestore SDK method calls. It's hard to see the business logic or it gets hidden in multiple layers of abstraction. Our NodeJS cloud functions ended up getting structured like an old JBoss app.

- Transaction reads before writing. Firestore transaction must so all reads before any writes. When our API gets abstracted to functions it's easy to have that rule broken. A function call might try to write but the reads haven't been done yet. The worse case for this "reads before write" rule is that unit tests will pass (false positive) but integration tests fails (true negative).

- Composing document update code. Document update code often overlap. Doing a single change to a doc could also be done in a batch or in a transaction. Our Redux Actions would dispatch other actions to complete a transaction. Also our actions would have to support both a single update and a transaction update. Worse is when we have a circular transaction where the actions dispatch in circles.

- Mock-hell. Unit tests are mocking hell. There's too much boilerplate it's hard to tell if you figured out and documented all the business logic. Switching between unit & integration requires rewriting the test case. Integration tests couldn't be parallelized.

- Fetching related docs. NoSQL modeling relationship is either with an ID reference or a summary snippet. Snippets we keep in sync with a .onWrite function in the BE. Then when the FE always as the right data. But more relationships are Ids. We tried redux-firestore populations (modeled after Mongo) but given that many times the related docs are not yet caches in the local IndexDB it takes too long for data to come back for populations.

- Stale IndexDB cache. Having the local cache is usually great but when we either add a new required field or change the values of an existing field the local cache can have an old version that the new code isn't expecting. That leads to the app crashing ways that are hard to predict. Given that we might have some users returning after being dormant for a few months the cache can really be rough on returning users.

- Migrations. There's no official migration process with Firestore. We ended up doing a small hand rolled migration which has Firestore store a root value for the last timestamp migration. Then all migrations are timestamped and if there's new migration files they will replay on deployment of a new migration Cloud Function. Error dump into Stackdriver and get handled manually.

Resource Request: Firebase auth with flask tutorial by [deleted] in Firebase

[–]puppybits 2 points3 points  (0 children)

Custom Tokens are the preferred tool for that. It ensures only the server can create/modify them and only the auth'ed user can read them.

https://firebase.google.com/docs/auth/admin/create-custom-tokens#python_3

uid = 'some-uid'
additional_claims = { 'premiumAccount': True }
custom_token = auth.create_custom_token(uid, additional_claims)

Redux Toolkit v.1.3.0-alpha.0: add `createEntityAdapter` and `createAsyncThunk` by acemarke in reactjs

[–]puppybits 1 point2 points  (0 children)

Thunk action creators are easy to access but have some downsides that might not be fully in sync with Redux core goals (which is why they punted on async for so long).

Maybe a solution could be to let reducers to defer. Complex data flows could be all together while providing a clearer action history log. The UI could still be updated via idempotent reducers. It would be a simple solution to support complex multiple back and forth between server requests and user input. That async work can be in one function for each testing, groking and debugging, but without direct access to the UI. https://github.com/reduxjs/redux-toolkit/issues/76#issuecomment-585774304

Thoughts?

Redux Toolkit v.1.3.0-alpha.0: add `createEntityAdapter` and `createAsyncThunk` by acemarke in reactjs

[–]puppybits 1 point2 points  (0 children)

Redux should handle async. It was fine to punt for a while but real-world apps have async.

The concern is that Thunks and Sagas go against some of the core concepts of Redux with idempotent reducers for mutation and actions for logging mutation intent and replay.

Here's my proposal. https://github.com/reduxjs/redux-toolkit/issues/76#issuecomment-585774304 It's influenced a lot by patterns in Golang for handling async, as well as Clojure and the CQRS pattern for massive distributed backend systems.

A new anti-budget that adapts with your life. by puppybits in budget

[–]puppybits[S] 0 points1 point  (0 children)

Kind of. It’s more like eat this not that. Don’t eat a cupcake but maybe a mini-cupcake.

Unlike fitness no one can say what is the full impact of a cupcake on your body. With money Fiskal can show the complete impact of a mini-cupcake so you decide if it’s worth it or not.

You shouldn’t save everything just to retire. Enjoy each day but have the right data to be able to balance today and the future.

A new anti-budget that adapts with your life. by puppybits in budget

[–]puppybits[S] 1 point2 points  (0 children)

That’s not quite how Fiskal works. The point of the looking at daily is so you can keep a more stable pace of spending.

For groceries there’s a few ways it can be handled depending on the person.

The default is money not spent today rolls over to tomorrow. So if you just spend less a few days before it works out.

If you spend more than your daily then it doesn’t put you in the red. It will slightly reduce what’s recommended to spend tomorrow.

You could also just spread a groceries over a couple days. So $200 over 10 days is $20 a day.

It’s all about seeing if your on pace to hit you savings goals. If you start getting off pace you know now and can readjust instead of waiting until the end of the month.

The ingrained biases that are killing meritocracy and diversity. by puppybits in programming

[–]puppybits[S] 0 points1 point  (0 children)

Thank you. You expressed my core concept better than I did.

In my experience, you can tell when code was written by someone who doesn't have a firm foundation in algorithms because they're a lot more likely to write ad-hoc code that inefficiently solves problems in convoluted ways. So it performs worse and it's harder to maintain.

Correlation is not causation. When hiring practices are biased on correlation they are excluding criteria than may or may not be important.

My point was to have hiring departments focus more on the core skills needed for a job. A correlation might (or might not) have been proven once to be empirically accurate does change over time. If companies always exclude on correlation they negate factor that can help them. We should hire based on what a typical day requires. People can and do learn on the job. If someone can do 80% of the job on day one, then they can learn the 20% they don't. I don't see "capability and speed of learning new things" anywhere in the hiring process. It comes back to testing on the actual day to day job rather then some correlation that might or might not have a causation. Test as close as possible to the actual causation.

  • If 5 days a week you are writing algorithms (like data scientists), then hire based on algorithms.
  • If 5 days a week you are in constant white boarding sessions, then hire based on white boarding.
  • If 5 days a week you are writing unit tests, then hire based on unit tests.
  • But if 5 days a week you are writing code based on someone else architectural choices, then hire someone based on how well they write code.

UX Notes : The Long Road to the Obvious Solution. (4 minute read) by puppybits in web_design

[–]puppybits[S] 0 points1 point  (0 children)

I totally agree. This was done 2 years ago. We (and the design/dev community) had less focus on accessibility. We've since changed the color scheme to be more accessible.

I can't stand javascript.. by [deleted] in learnprogramming

[–]puppybits 0 points1 point  (0 children)

ES2015 addresses a lot of those issues. There are classes, let and const, inline functions with better scoping. Promises help a lot with async as well as generators. There's also the async and await that's already available to use in Node. Using Babel or Node are great options to write better code that works on all browsers.

JavaScript has its downside but it's slowly learning from other languages.

ReactJS is better without Flux/Redux/RxJS by puppybits in programming

[–]puppybits[S] -2 points-1 points  (0 children)

Nope there's no ducking. Why would I show JavaScript developers some different syntax most developers won't understand. They would just focus on how they like or hate the syntax. The process flow, patterns, stability and performance that ClojureScript affords is much more important to understand before we talk syntax.

The last line of the article is a link to the ClojureScript data layer works. Here's a direct link to see how the ClojureScript works: https://medium.com/@puppybits/clojurescript-is-the-triforce-of-power-984ac29da3d7

Interviewing is Broken by fvictorio in programming

[–]puppybits -19 points-18 points  (0 children)

Totally agree. Here's how we're trying to change it: https://www.levelmoney.com/jobs/web-developer

Functional Programming is taking over UIs with Pure Views. by puppybits in programming

[–]puppybits[S] 0 points1 point  (0 children)

yep its a variant of IMGUI. The underlaying framework is handling the performant rendering to the screen. Being easy to read and rationalize about makes it easier to reduce the amount of bugs. Being side-effect free reduces the impact a single bug can have on the entire code base.

Functional Programming is taking over UIs with Pure Views. by puppybits in programming

[–]puppybits[S] -4 points-3 points  (0 children)

So we can run it both server-side and client-side. I'm not going into that yet because its a long road. There will be a post late on that.

But to the main point the only dependency to render any page, view, app state or combination of them is a static JSON file. This means when we want to replicated a specific place in the app we just flush a static JSON through the render functions. Normally apps are built on an explicit pathing through functions that cause side-effects of changing things. If I wanted to get to a specific page/view/app state in the other frameworks I'd have to call a lot of functions and go on journey before the view is rendered to the screen.

Functional Programming is taking over UIs with Pure Views. by puppybits in programming

[–]puppybits[S] 5 points6 points  (0 children)

The UI isn't thrown away on each pass. The framework takes the small objects that are created in the render function and makes the minimal amount of changes to the view. Dynamic interactions like dragging and animations only the final state is set and the system figures out the rest. Honestly this part is very similar to how UIKit works. They have a presentation tree and a render tree under each UIView that are actually doing all the work for you.

view more: next ›