Hacker News new | past | comments | ask | show | jobs | submit | drabinowitz's comments login

I was really hoping this would come with rollback support for deployments. That, to me, would be the big advantage of having gcp manage the tfstate. It doesn’t look like that’s currently supported, but maybe that’s coming in the future.


Are you thinking of this as separate from a revert to the Terraform files and then a roll forward?


Yeah if I have multiple terraform projects in one repo it would be helpful to have a UI show deployments for each project with a list of rollouts so I can see which one I want to go back to. For SREs it might not be as helpful but if you delegate some scoped terraform module creation to the developers themselves it’d help them to have a simple UI for rollbacks


Ah yeah I see what you mean. At my last (big tech fwiw) shop as we were transitioning to GitOps, we ran into this issue a lot. My current gig we're too small for this to be a big issue for us but I remember the pain well.


You can include a locked_at field and have your update query be for not_started rows and started rows where locked_at is older than the job timeout


A global job timeout might be unreasonable with high variance in workload. Eg some jobs taking 0.5 seconds and others 30 seconds. You might set a global timeout of say 60s but it sucks to wait 59.5s to reap that short job whose worker crashed. A better system is to make workers update a timestamp on an interval and you reap any jobs that haven't been updated in N seconds.


It's a trade off between updates per sec and latency.

Maybe simply using a timeout per job type is a better way. (That of course trades off simplicity.)


I agree. Frequency of updates also becomes more of an issue as you add workers. Say you have 1000 workers each updating every 2 seconds. That's ~500 timestamp update statements per second which is not trivial in terms of added load on the DB.


That's an interesting dataset and it aligns with my gut reaction: TDD (and testing in general) are ideal for bug fixes and code refactoring, which would be less useful when the software is going to be sold at a specific point in time (and therefore frozen or mostly frozen).


I've been considering building a pwa and using a webview as a pseudo native app I know iOS support isn't great but it seems to be improving and iOS push notifications could be built separately in the meantime. How's anyone tried this approach?


While PWA’s largely work, they provide a poor installation experience and little device integration. Most people use Apache Cordova, PhoneGap, or Ionic as wrappers to their mobile web app, providing expected installation experiences through app stores and common device integrations.


Are you really asking if someone has tried putting their website inside a webview and call it an “app”?

Have you heard of Electron, Cordova and tons of other crapware that help produce so much garbage “apps” every year, it would put to shame even the most toxic enterprises in an unregulated Republican dream?


Type guards also allow you to use Array.prototype.filter to modify the type of an array ie

  const maybePets: Array<Pet | undefined> = [...]
  const pets: Array<Pet> = maybePets.filter((v: Pet | undefined): v is Pet => v != undefined)
Will compile without errors.


I wonder if it would makes sense to enforce hooks being called through a top level React function. To make some of the ordering more explicit

  function MyReactComponent() {
    const [
      [width, setWidth],
      [name, setName],
    ] = React.use(
      [useWidth],
      [useName, 'alice'],
    );
    return <div>{width} {name}</div>
  }
admittedly, this is much less clean looking than the current proposal, but, in my mind at least, it makes it a bit more clear that you have to pass the functions in with a specific order at the top of the component.


I don't understand what exactly you're trying to solve by this (nothing prevents a user from making it conditional) but it definitely has flaw #7 (can't pass values between Hooks).


Ah that's fair about flaw #7


This is a really cool implementation! I'm wondering if it wouldn't be possible to handle optimistic updates by submitting a request to the server and then submitting an optimistic response from the client to itself. Then, when the server comes back, you hook into the already present optimistic response and just confirm or deny it based on the response from the server. That way you keep as little state on the client as possible.


Thanks so much for letting us know we will take a look first chance we get.


Currently we have been focusing on a purely client side implementation, that being said our features are largely built to extend React and Flux and that should put us in a strong position to work with Isomorphic apps down the line.


Yeah I apologize for that we are still working on a mobile friendly version of the site.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: